United States Patent 


[19] 


nil 

US006005942A 
[n] Patent Number: 
[451 Date of Patent: 


6,005,942 
Dec. 21, 1999 


[54] SYSTEM AND METHOD FOR A MULTI- 
APPLICATION SMART CARD WHICH CAN 
FACILITATE A POST-ISSUANCE 
DOWNLOAD OF AN APPLICATION ONTO 
THE SMART CARD 

[75] Inventors: Alfred Chan, Daly City; Marc B. 

Kekicheff, Palo Alto; Joel M. Weise, 
Burlingame; David C. Wentker, San 
Francisco, all of Calif. 

[73] Assignee: Visa Internationa] Service 

Association, Foster City, Calif. 

[21] Appl. No.: 09/046,993 
[22] Filed: Mar. 24, 1998 

Related U.S. Application Data 
[60] Provisional application No. 60/061,763, Oct. 14, 1997, and 
provisional application No. 60/041,468, Mar. 24, 1997. 

[51] Int. CI. 6 H04L 9/00; H04L 9/08; 

G07F 7/08 

[52] U.S. CI 380/25; 380/9; 380/21; 

380/23; 380/24; 380/29; 380/30; 380/49; 

380/50; 235/379; 235/380 

[58] Field of Search 380/4, 23, 24, 

380/25, 49, 50, 59, 9, 21, 29, 30; 235/379, 
380, 382; 379/93.01, 93.05, 93.06, 93.12 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,742,215 5/1988 Daughters et al 235/487 

5,332,889 7/1994 Lundstrom et al 235/380 

5,378,884 1/1995 Lundstrom et al 235/380 X 

5,530,232 6/1996 Taylor 235/380 

5,583,933 12/1996 Mark 380/9 X 

FOREIGN PATENT DOCUMENTS 

E 100227 11/1994 Austria . 
0193635 Al 9/1986 European Pat. Off. . 
19607363 Al 9/1996 Germany . 

OTHER PUBLICATIONS 

EPO, International Search Report, Jut. 3, 1998, International 
Application No. PCT/US 98/05674. 
Carol Hovenga Fancher,"In Your Pocket Smart Cards", Feb. 
1997, IEEE. 

Chaum et al., "Smart Card 2000; The Future of IC Cards", 
Oct. 19, 1987, Elsevier Science Publishers B.V. 
Steven Levy, "E-Money (That's What I Want)", Dec. 1994, 
Wired Magazine, 

Carol H. Fancher, "Smart Cards as Potential Applications 
Grow, Computers in the Wallet arc Making Unobtrusive 
Inroads", Aug, 1996, Scientific American Website. 
Jerome Svigals, "Smart Cards The New Bank Cards", 1985, 
MacMillan Publishing Company. 

Roy Bright, "Smart Cards: Principles, Practice, Applica- 
tions", 1988, Ellis Horwood Limited. 
Jerome Svigals, "Smart Cards The Ultimate Personal Com- 
puter**, 1985, MacMillan Publishing Company. 
Hawkes et al., "Integrated Circuit Cards, Tags and Tokens", 
1990, BSP Professional Books. 


Hiro Shogase, "The Very Smart Card: A Plastic Packet 

Bank", Oct. 1988, IEEE Spectrum. 

David Naccache, "Cryptographic Smart Cards**, Jun. 3, 

1996, IEEE Micro 1996 Website. 

Zoreda et al., "Smart Cards", 1994, Artech House. 

"Identification Card Systems — Inter-^Sector Electronic 

Purse Part 1: Concepts and Structures", 1994, European 

Standard, prEN 1546. 

"Identification Card Systems — Inter-Sector Electronic 
Purse Part 2: Security Architecture", 1994, European Stan- 
dard, prEN XXXXX-2. 

"Identification Card Systems — Inter-Sector Electronic 
Purse Part 3: Data Elements and Interchanges*', 1994, Euro- 
pean Prestandard, prEN 1546-3. 

"Identification Card Systems — Inter-Sector Electronic 
Purse Part 4: Devices", 1994, European Prestandard, prEN 
1546-4. 

"Identification Cards — Integrated Circuit(s) Cards With 
Contacts Part 1: Physical Characteristics", 1987, Interna- 
tional Standard, ISO 7816-1, First Edition. 
"Identification Cards — Integrated Circuit(s) Cards With 
Contacts Part 2: Dimensions and Location of the Contacts", 
1988, International Standard, ISO 7816-2, First Edition. 
"Identification Cards — Integrated Circuit(s) Cards With 
Contacts Part 3: Electronic Signals and Transmission Pro- 
tocols", International Standard, ISO/IEC 7816-3, First Edi- 
tion. 

"Identification Cards — Integrated Circuits) Cards With 
Contacts Part 4: Inter-Industry Commands for Interchange", 
International Standard, ISO/IEC 7816-4, First Edition. 
"Identification Cards — Integrated Circuit(s) Cards With 
Contacts Part 5: Numbering System and Registration Pro- 
cedure for Application Identifiers", 1993, International Stan- 
dard, ISO/IEC DIS 7816-5. 

"Identification Cards — Physical Characteristics**, 1995, 
International Standard, ISO/IEC 7810, Second Edition. 
"Identification Cards-Recording Technique — Pari 1: 
Embossing*', 1995, International Standard, ISO/IEC 
7811-1, Second Edition. 

(List continued on next page.) 

Primary Examiner — Bernarr E. Gregory 
Attorney, Agent, or Firm — Beyer & Weaver, LLP 


[57] 


ABSTRACT 


A system and method allow card issuers to securely add 
applications during the lifetime of the card after the card has 
already been issued (post issuance). Loading of an applica- 
tion and/or objects from an application server via a card 
acceptance device (and its supporting system infrastructure 
delivery mechanism) onto a card post issuance is performed 
in a secure and confidential manner, A smart card includes 
a card domain application that manages the card. Any 
number of security domain applications on the card provide 
security for loaded applications by managing keys; each 
application is associated with a security domain. Each of the 
card domain and security domains has a command interface 
for off-card communication, and an API for internal card 
use. The card life cycle includes the states of masked, 
initialized, load secured and blocked. An application life 
cycle includes the states of not available, loaded, installed, 
registered, personalized, activated and blocked. An applica- 
tion can block the card. 

24 Claims, 15 Drawing Sheets 
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SYSTEM AND METHOD FOR A MULTI- standard routines, and look up tables. Non-volatile memory 

APPLICATION SMART CARD WHICH CAN 18 (such as EPROM or EEPROM) serves t o store infor- 

FACILITATE A POST-ISSUANCE mation that must not be lost when the card is disconnected 

DOWNLOAD OF AN APPLICATION ONTO from a power source but that must also be alterable to 

THE SMART CARD 5 accommodate data specific to individual cards or any 

changes possible over the card lifetime. This information 

CROSS REFERENCE TO RELATED might include a card identification number, a personal 

APPLICATIONS identification number, authorization levels, cash balances, 

. ( . . . ■ . . no • ■ i i- credit limits, etc. Cryptographic module 22 is an optional 

I nis application claims priority to U.S. provisional apph- . , . . K * e - * 

cation Ser No. 60/061,763 filed Oct. 14, 1997, which is 10 hardware module used for performing a variety of crypto- 

herein incorporated by reference. This application further 8 ra P hlc a,g ° r " ^ ' T u 

claims priority to U.S. provisional application Ser. No. ^ f,ware , aad h fi dware , Qecessar y { ? r communication with 

60/041,468 filed Mar. 24, 1997, which is also herein incor- ' he ouls,de r world * w ! de V™'^"' ,merfaces »™ P 0SSlble - 

porated by reference B y wa ^ of exam P le . ,nlerracc 24 ma V P rov,de a conlact 

r J 15 interface, a close-coupled interface, a remote-coupled 

This application is related to U.S. application Ser. No. interfacei or a varie t y 0 f other interfaces. With a contact 

09/046,994, filed on Mar. 24, 1998 which is also herein interface) signals fromthe micro-controller are routed to a 

incorporated by reference for all purposes. number of meta , contacts on , be outside of the card whkn 

FIELD OF THE INVENTION come in physical contact with similar contacts of a card 

20 reader device. 

The present invention relates to smart cards. In particular, Various mechanical and electrical characteristics of smart 

the present invention relates to a system and method for carc j 5 anc j aspects of its interaction with a card reading 

providing a multi-application smart card which can facilitate device are defined by the following specifications, all of 

a post-issuance download of an application onto the smart which are herein incorporated by reference. 

carc *' 25 Visa Integrated Circuit Card Specification, (Visa Interna- 

BACKGROUND OF THE INVENTION tional Service Association 1996). 

EMV Integrated Circuit Card Specification [or Payment 

A smart card is typically a credit card-sized plasticj;ard Systems, (Visa International Service Association 1996). 
that includes a semiconductor chip capable of tfg^g^ataTV EMV integrated Circuit Card Terminal Specification for 

c suppomng:multiple. applications^ 30 Paymeng SystemSy (V isa International Service Association 

Physically, a smart card often resembles a traditional 1996). 

"credit" card having one or more semiconductor devices EM y integrated Circuit Card Application Specification 

attached to a module embedded in the card, providing f or Payment Systems, (Visa International Service Associa- 

contacts to the outside world. The card can interface with a uon 1995). 

point-of-sale terminal, an ATM, or a card reader integrated 35 international Standard, Identification Cards-Integrated 

into a telephone, a computer, a vending machine, or any Circuit(s) Cards with Contacts, Parts 1-6 (International 

other appliance. Standards Organization 1987-1995). 

A micro-controller semiconductor device embedded in a Prior t0 issuance of a smart card to a card user, the smart 

"processor" smart card allows the card to undertake a range 4Q card is initialized such that some data is placed in the card, 

of computational operations, protected storage, encryption Initialization refers to the population of non-volatile 

and decision making. Such a micro-controller typically memory with data that is common to a large number of cards 

includes a microprocessor, memory, and other functional while also including a minimal amount of card unique terms 

hardware elements. Various types of cards are described in ( e gt carc j number and personalization keys). For 

"The Advanced Card Report: Smart Card Primer", Kenneth 45 examp i c , during initialization, the smart card may be loaded 

R. Ayer and Joseph F Schuler, The Schuler Consultancy, w ; tn at least one application, such as credit or stored cash 

1993. value, a file structure initialized with default values, and 

One example of a smart card implemented as a processor some initial cryptographic keys for transport security. Once 

card is illustrated in FIG. 1. Of course, a smart card may be a card is initialized, it is typically personalized. During 

implemented in many ways, and need not necessarily ™ personalization, the smart card is loaded with data which 
include a microprocessor or other features.ll@|s^ajpc^ra'3 uniquely identifies the card. For example, the personaliza- 
^mayibe^ogr.ar^medrwith'various types orfunclionaljty,;? tion data can include a maximum value of the card, a 

•in|ju^ing^appUcati6^^ personal identification number (PIN), the currency in which 

^loya^progr^n^gto-^ the card is valid, the expiration date of the card, and 

In some embodiments, smart card 5 has an embedded 55 cryptographic keys for the card, 

micro-controller 10 that includes a microprocessor 12, ran- A limitation of conventional smart cards is that new 

dom access memory (RAM) 14, read-only memory (ROM) applications typically can not be added to an issued smart 

16, non-volatile memory 18, a cryptographic module 22, and card. Smart cards are traditionally issued with one or more 

a card reader interface 24. Other features of the micro- applications predefined and installed during the manufac- 

controller may be present but are not shown, such as a clock, 60 turing process of the card. As a result, with traditional smart 

a random number generator, interrupt control, control logic, card implementation, once a card has been issued to a card 

a charge pump, power connections, and interface contacts user, the smart card becomes a fixed application card. If a 

that allow the card to communicate with the outside world. new application is desired, the smart card is typically 

Microprocessor 12 is any suitable central processing unit discarded and a new smart card, which includes the new 

for executing commands and controlling the device. RAM 65 application, is issued. 

14 serves as storage for calculated results and as stack It would be desirable to provide a smart card which would 

memory. ROM 16 stores the operating system, fixed data, allow applications to be loaded after the card is issued. 
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Further, it is desirable to provide a mechanism to manage the FIG. 7B is a flow diagram illustrating a sequence of card 

loading of an application as well as general management of life states. 

the applications on the smart card. Additionally, it is desir- FIG. 8 is an illustration of an example of a card life cycle. 

able to allow an application provider to keep cryptographic nG 9 ^ a fiow diagram of an examplc of a mcihod 

keys confidential from the u>sucr of the smart card and to 5 according l0 an embodiment of the present invention for 

securely allow applications from different entities to coexist blocking a card utilizing a card domain. 

on a card. . ..... ... 

FIG. 10 is a block diagram illustrating interactions 

SUMMARY OF THE INVENTION between a card domain and a security domain on a smart 

Embodiments of the present invention teach a system and 10 card wording to an embodiment of the present invention. 

method which allow card issuers to add applications during FIGS. 11A and 11B are flow diagrams of an example of 

the lifetime of the card after the card has already been issued a method according to an embodiment of the present inven- 

(referred to herein as post issuance loading). Downloading tion for loading an application by using a security domain 

an application after the card has been issued to the card after the smart card has issued. 

holder will be referred to herein as a "secure install" process, is FIGS. 12A-12B are flow diagrams of an example of a 

The system and method according to embodiments of the method according to an alternate embodiment of the present 

present invention allow the post issuance loading of an invention for loading an application using a security domain 

application and/or objects from an application server via a after the smart card has issued. 

card acceptance device and its supporting system infrastmc- FIG. 13 is a block diagram illustrating an example of key 

ture delivery mechanism onto a card in a secure and confi- 20 management and key dependencies for post issuance down- 

denlial manner. load of applications onto the smart card. 

An embodiment of the present invention provides a 

system and method for controlling at least one function DETAILED DESCRIPTION OF THE 

associated with an issued smart card. In a multiapplication PREFERRED EMBODIMENTS 

smart card, a privileged application, herein referred to as a 25 -j^e following description is presented to enable one of 

card domain, manages multiple functions related to the ordinary skill in the art to make and to use the invention and 

smart card. Examples of these functions include card ^ prov ided in the context of a patent application and its 

initialization, global card data, card life cycle, and secure requirements. Various modifications to the preferred 

installation of smart card applications. embodiments will be readily apparent to those skilled in the 

A method according to an embodiment of the present art and the generic principles herein may be applied to other 

invention for providing a first application onto an issued embodiments. Thus, the present invention is not intended to 

smart card comprises the steps of forwarding the first be limited to the embodiment shown but is to be accorded 

application to the issued smart card; and loading the first the widest scope consistent with the principles and features 

application onto the issued smart card, wherein the loading described herein. 

of the first application is managed by a second application. 35 FIG. 2 is a block diagram of an example of software layers 

In another aspect of the invention, a system according to which can be utilized in a smart card. The smart card shown 

an embodiment of the present invention for controlling at i n FIG. 2 includes an operating system 200, a card applica- 

least one function associated with an issued smart card is tion programming interface (API) 204, and applications 

disclosed. The system comprises a first application associ- 4Q 206A-206B. Operating system 200 can include functional- 

ated with the issued smart card; and a second application ity to control the cards, memory management, input/output 

associated with the issued smart card, the second application (I/O), and cryptographic features. Card API 204 utilizes the 

being in communication with the first application, wherein instructions from operating system 200 and writes these 

the second application manages at least one function asso- instructions into blocks which can be reused for common 

ciated with the first application. 45 routines in multiple applications. Applications 206A and 

BRIEF DESCRIPTION OF THE DRAWINGS 206B can run o n th c | sma rt c ar d via ins tructions from API 

2u^jfoeselaW :lie^ 

FIG. 1 is a block diagram of a smart card system suitable fejnjfiin^ ^ 

for implementing the present invention. ^S^^Sy^^ — ^3^a^s_^— 

nG.2isanexampleofablockdiagramofsoftware layers 5Q 0ne cmbodin £ nl of the presenl invention is based upon 

which can be utilized in a smart card. the ggsagajgaggSfflvIn this case applications are referred 

FIGS. 3A-3B are block diagrams of examples of software t0 as 'Applets' and they a^raufSuMinT&t^ 

layers according to embodiments of the present invention. which is the application programming~interface pTe^ent^on 

FIG. 4 is a flow diagram of an example of a method smart cards built to the Java Card standard, 

according to an embodiment of the present invention for 55 Although the conventional software system shown in 

installing an application onto an issued smart card utilizing FIG 2 allows for multiple applications, it does not solve the 

a card domain. problem of how to securely load an application after issu- 

FIG. 5 is a flow diagram of a method according to an ance 0 f tDC smart card to a user. If an application is to be 

embodiment of the present invention for providing confi- loaded post issuance, a mechanism is needed to manage the 

dential information to an application in a smart card using 60 loading of an application as well as the general management 

security domains. of the applications on the smart card. Additionally, an 

FIG. 6 is a flow diagram of an example of a method application provider may wish to keep cryptographic keys 

according to an embodiment of the present invention for confidential from the issuer of the smart card. Accordingly, 

installing an application onto an issued smart card utilizing a mechanism is needed to provide for the separation of 

a card domain. 65 confidential information between an application provider 

FIG. 7A is a flow diagram illustrating a sequence of card and an issuer of a smart card. Embodiments of the present 

life states. invention address such a need. 
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FIGS. 3A-3B are block diagrams showing software com- 
ponents of a smart card according to embodiments of the 
present invention. The arrows indicate dependencies 
between components, FIG. 3A shows an embodiment of a 
smart card utilizing a card domain, while FIG. 3B shows an 
embodiment of a smart card utilizing a security domain, as 
well as a card domain. 

The example shown in FIG. 3A includes an operating 
system 300, a card API 304, applications 305A-305C, a card 
domain 308, and open platform (OP) API 306. The system 
shown in FIG. 3 allows for a secure and managed post 
issuance download of an application onto a smart card. A 
card domain is a card issuier's on-card control mechanism 
for a smart card according to the present invention. 

Open platform API 306 classifies instructions into card 
domain 308 and security domains 310A-310B (shown in 
FIG. 3B). Accordingly, OP API 306 facilitates the formation 
of instructions into sets which can be identified as being 
included as part of card domain 308 and security domains 
310A-310B. 

Applications 305A-305C can include any application 
which can be supported by a smart card. Examples of these 
applications include credit, debit, stored value, transit, and 
loyalty. Applications 305A-305C are shown to include 
command interfaces, such as APDU interfaces 354A-354C 
which facilitate communication with the external environ- 
ment, APDU stands for "Application Protocol Data Unit" 
and is a standard communication messaging protocol 
between a card acceptance device and a smart card. A 
command is a message sent by the terminal to the smart card 
that initiates an action and solicits a response from the smart 
card. 

Applications 305A-305C can run on the smart card via 
instructions from card API 304. Card API 304 is imple- 
mented using the instructions from the card operating sys- 
tem and writes these instructions into blocks which can be 
reused for common routines for multiple applications. Those 
skilled in the art will recognize that a translation layer or 
interpreter may reside between API 304 and operating 
system 300. An interpreter interprets the diverse hardware 
chip instructions from vendor specific operating system 300 
into a form which can be readily utilized by card API 304. 

Card domain 308 can be a "privileged" application which 
represents the interests of the smart card issuer. As a 
"privileged" application, card domain 308 may be config- 
ured to perform multiple functions to manage various 
aspects of the smart card. For instance, card domain 308 can 
perform functions such as installing an application on the 
smart card, installing security domains 310A-310B (shown 
on FIG. 3B), personalization and reading of card global data, 
managing card life cycle states (including card blocking), 
performing auditing of a blocked card, maintaining a map- 
ping of card applications 305A-305C to security domains 
310A-310B, and performing security domain functions for 
applications 305A-305C which are not associated with a 
security domain 310. 

Card domain 308 is shown to include an API 350 and a 
command interface, such as Application Protocol Data Unit 
(APDU) interface 352. APDU interface 352 facilitates inter- 
facing with the external environment in compliance with, e., 
International Standards Organization (ISO) Standard 7816- 
4, entitled "Identification Cards — Integrated circuit(s) cards 
with contacts — Part 4, Inter-industry commands for 
interchange," which is herein incorporated by reference. 

For example, APDU interface 352 can be used during post 
issuance installation of an application or during loading of 
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card global data. An application load and install option is 
performed via a set of appropriate APDU commands 
received by card domain 308. API 350 facilitates interfacing 
with the internal smart card environment. For example, API 

5 350 can be used if card domain 308 is being utilized as a 
default in place of a security domain 310, or if an application 
requires information such as card global data, key derivation 
data, or information regarding card life cycle. In other 
words, Card Domain 308 via API 350 also processes, 

3Q APDUs for functions such as: reading ICC serial number, 
managing the card life cycle state including providing a card 
blocking service (the issuer is responsible for determining 
which applets, if any, can use the card blocking service), 
performing auditing for the card (when the card is blocked 

35 these are the only APDUs that will be handled), maintaining 
a mapping of security domains to applets, and acting as the 
security domain for the issuer's applets. 

Memory allocations have been performed by the time an 
application is in an install state. An application is also 

20 personalized after loading and installing. A personalized 
application includes card holder specific data and other 
required data which allows the application to run. In addition 
to managing the installation and personalization of the 
application, card domain 308 can also manage global card 

25 information. Global card information includes information 
that several applications may need to perform their 
functions, such as card holder name and card unique data 
utilized in cryptographic key derivations. Card domain 308 
can be a repository for the global card information to avoid 

30 storing the same data multiple times. 

Card domain 308 can also manage card life cycle states 
including card blocking. The smart card will typically move 
through several states during its life cycle. Card domain 308 
keeps track of what state the card is in during its life cycle. 

35 Card domain 308 may also manage a block request to block 
virtually all functions of the card. Further details of card 
domain 308 management of a block request will be dis- 
cussed in conjunction with FIG. 6. Card domain 308 may 
also keep track of the state of an application during an 

40 application's life cycle. This kind of information regarding 
an application can be utilized during an auditing of a card. 
Auditing can be performed at any time during a card's 
lifetime. For instance, auditing may be performed after a 
card has been blocked or prior to installing a new application 

45 to validate the card contents. Although virtually all card 
functions are no longer functioning when a card is blocked, 
an issuer may be able to query card domain 308 for 
information regarding a state of an application or the life 
cycle state of the card. In this manner, the issuer of a card 

50 may still access a profile of the blocked card and its 
applications. 

FIG. 3B shows an embodiment of the present invention 
utilizing a security domain 310, as well as card domain 308'. 
The example shown in FIG. 3B includes an operating system 

55 300', a card API 304', applications 305A-305C, security 
domains 310A-310B, a card domain 308', and open plat- 
form (OP) API 306'. TfcMfl^ 
ajUows;for>~ secure a nd mawged'posrissua nee download, offs^ 
^J^iTpplie^ ; 

60 C^^bm ain'368^can"work inconj unction wi th a secu rity 
domain 310. Security domain 310 is a logical construct that 
can be implemented as an application to provide security 
related functions to card domain 308' and to applications 
associated with security domain 310. Security domains 

65 310A-310B can assist in secure post issuance loading of an 
application onto the smart card. Security domains 
310A-310B provide for a mechanism which keeps the 
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application provider's confidential information, such as on a post issuance basis. MAC stands for "Message Authen- 

cryptographic keys, from being disclosed to the issuer of the tication Code" and is a symmetric cryptographic transfor- 

smart card. mation of data that protects the sender and recipient of the 

There may be multiple security domains 310 on a smart data against forgery by third parties, 

card, each represented by a unique cryptographic relation- 5 The smart card issuer may decide whether security 

ship. A security domain 310 is responsible for the manage- domain 310 utilizes a static key or a session key for 

ment and sharing of cryptographic keys and the associated transactions. Astatic key is a cryptographic key which exists 

cryptographic methods which make up the security prior to processing APD Us and which exists during and after 

domain's cryptographic relationship. An application which the processing of APDUs. A session key is a cryptographic 

is loaded to the smart card post issuance can be associated 10 key which can be generated for a particular transaction and 

with a security domain, preferably with only one security is typically no longer used for APDU processing after the 

domain. However, multiple applications may be associated transaction. If a session key is utilized, security domain 310 

with the same security domain 310. Applications installed preferably derives its own session key for processing 

on a smart card during the pre-issuance phase may option- APDUs. 

ally be associated with a security domain 310 on the smart ^ The APDU interface implemented by security domains 

card for purposes of loading confidential personalization consists of the initialization and personalization command 

data to those applications using security domain 310 keys. A ^ These commands are intended to load security domains, 

security domain is the logical representation of an applet to allow the initial loading of keys and to support key 

provider's encryption and signature keys on a smart card rotation. The general sequence of APDUs to establish one 

according to the present invention. 20 security domain is; lt SELECT (Card Domain); 2. Perform 

The software for security domain 310 may be installed by authorization; 3. INSTALL (Security Domain); 4. Multiple 

the card manufacturer at the time of card manufacturing LOAD (applet — executable); 5. INSTALL (install — and — 

(e.g., when the ROM is masked), or may be added during register); 6. SELECT (SecurityDomainID); 7. PUT — KEY 

initialization or personalization stages. Security domains (SD encryption key encrypted with Card Domain initializa- 

310 can be implemented as selectable applications which are 25 tion key); 8. Optional PUT — KEY (SD signature key 

isolated from one another and the rest of the system. If encrypted with SD encryption key), 
security domain 310 is implemented in a Java card as an 

application, standard Java card security can be reb'ed upon JAVA EMBODIMENT 

to ensure isolation of security domain 310. In addition, or 0ne embo diment of the present invention makes use of 

alternatively, other security mechanisms such as hardware the JAVA Card standard M^atiorr^^th-e^d^rii> 

security can be utilized through OP API 306 implementa- .teetuTelgS^^ 

tion. OP API 306 may utilize special security features to ^ialr n^ 

enforce isolation of security domain 310. An example of iflls^ffnforces sepa^ 

such a security feature is the utilization of chip hardware data sharing . Abov^he^rtual*^ 

security routines which may be employed by OP API 306. ^arti^f^^ 

Each security domain 310A-310B provides a command /wgti ng |fpp|g^fo ^^ 

interface, such as an Application Protocol Data Unit ^classes provide a luglf level language interface to the under- 

(APDU) interface 320A-320B, for communication off card, lying functionality required by card applets which include 

and on card APIs 322A-322B. 4Q the APDU buffer, commit/role back functionality, data 

The APDU interface 320A or 320B consists of personal- sharing, and life cycle state. The classes are implemented in 

ization commands and is intended to allow the initial loading a mix of JAVA and native methods (i.e., assembly language) 

of security domain keys and to support key rotation if enabling applets to be implemented in pure JAVA without 

desired during the life of the security domain. APIs using native methods. This distinction enables easier veri- 

322A-322B may include a signature verification method 45 fication of applet behavior and enforcement of security. It 

and decryption method which arc shared with card domain also means that the primitive functionality that applets 

308' for post issuance loading of applications. Additionally, require is contained in this API. In this embodiment, open 

applications may utilize API interfaces 322A-322B for platform API 306 provides base classes for the development 

decrypting application confidential data. Note that card of applets, security domains, and the card domain. OP API 

domain 308' may always function as a security domain and 50 306 describes additional packages for supporting the OP 

does so as the default. environment on a JAVA card. These packages provide the 

Security domain 310 manages signing and decrypting foundation for implementing the Card Domain applet and 

keys and provides cryptographic services using those keys. Security Domain applets. 

Security domain 310 processes APDU's for numerous func- Also included in this embodiment is a Card Executive 

tions. These functions can include key management 55 which is responsible for dispatching APDUs to the current 

functions, e.g., functions to load or update keys. During a applet and selection of the current applets. The Card Exccu- 

secure installation of an application, security domain 310 live selects an applet to become the current applet when a 

can provide services to card domain 308' to decrypt an SELECT APDU is received. The Card Executive dispatches 

application install file and check the signature of an appli- a non SELECT APDU by calling the current applets process 

cation file. For an application associated with a security 60 method, 

domain 310, that application's security domain 310 provides When receiving a SELECT APDU a Card Executive acts 

decrypt and signature functions, such as MACing on an as follows. If the application identifier in the SELECT 

update key APDU command during the personalization APDU belongs to a selectable applet (i.e., an applet in the 

phase of a newly installed application. Thereafter, the appli- personalized STATE) the Card Executive makes that applet 

cation can use the updated key to decrypt and check signa- 65 the current applet which will receive subsequent APDUs. 

lures on subsequent key updates. An install file is a specific The Card Executive calls the applets select method. Notice 

data construct format for downloading data onto smart cards that this method enables the current applet to handle 
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SELECT APDUs as long as the application identifier in the existence of this cryptographic relationship allows more 

APDU is not for another selectable applet. than one applet owner to be represented on the card. Each 

The Card Domain is a special system applet representing 0WDer ' based u P on their c o^o\ of their cryptographic 

the card issuer. It provides platform wide (or "card global") relationship is thus responsible for the security and integrity 

services. The Card Domain processes APDUs for the fol- 5 o f all applets within their Security Domain, 

lowing functions: installing applets on the card; personaliz- POST-ISSUANCE LOADING 

ing and reading card global data, such as card serial number; FIG. 4 is a flow diagram of a method accordingly to an 

managing the card life cycle state including providing a card embodiment of tbe present invention for providing an a u . 

blocking service (the issuer is responsible for determining ca , ion , 0 a smart card ^ e , e iUustraled in FIG . 4 ^ 

which applets if any, can user the card blocking service); 10 ^ instaUin a securf domain m QMo a smart card 

performing aud.tmg for tte card when the card * blocked Note , hat aU of ^ flow di s jn ^ are 

these are the only APDUs that will be handled; maintaining merel e les . According i V) Ae iUu strated steps of this 

a mapping of security domains to applets; and acts as the a[]d olhef Qqw dj can Qccur fa varfous Qrders and 

secunty domain for the issuer s applets. fa varyjng mannere fa order tQ accomplish virtually lhe same 

A Security Domain is a special applet owned by an applet g 0a | 
provider to control the installing of the provider's applets. It A smart card is issued (step 400) and an app i ication is 
manages signing and decrypting keys and provides crypto- forwarded to the issued smart card (step 402). The forward- 
graphic services using those keys. A Security Domain pro- ug of the appIication can through any electronic 
cesses APDUs for the following functions: key set load; key media which can i nler f ace ^ a sraarl al6 and connect l0 
update; and key set switch. During secure install of an an appropriate network. For example, devices such as an 
applet, the Secunty Domain provides services to the card automatic teller machine (ATM), a display phone, or a home 
domain to decrypt an applet install file and check the computer, can be used to forward an application to tbe issued 
signature on an applet file. For an applet associated with a smart ^ ^ forwarded application is then loaded onto 
Security Domain, tbe Secunty Domain provides decrypt and lne smarl card> and me loading of the application is managed 
MAC functions on the Update Key APDU during the by card domain 308 (step 404). 

personalization phase of the newly installed applet. 'ITiis is F|(J 5 ta another flow dj of , melhod accordi lo 

done exactly once: thereafter the applet can use the updated an embodimem of the present invention for providing all 

key to decrypt and check the MAC on the subsequent Key application onto an issued smart card. A smart card is created 

Updates. ASecunty Domain denves it sown session key for ^ and pr£)vided ^ a firs , application) the firsl application 

processing Aruus. including a cryptographic service (step 1002). A second 

The virtual machine and Card Executive must be func- application is loaded onto the smart card (step 1004). 

tional before any applet can be selected. As part of card Thereafter, the second application is installed, and the cryp- 

initialization the Card Domain applet is installled and reg- tographic service of the first application is utilized to install 

istered. It can then be selected and personalized (e.g. with 35 the second application (step 1006). 

card global data and it's own keys). After that it can be FIG. 6 is another flow diagram of an example of a method 

selected and used to install other applets. Card initialization according to an embodiment of the present invention for 

includes the following steps: the Card Domain is installed prov iding an application onto an issued smart card. This 

and registered during the bootstrapping process of the first me thod for providing an application also applies to provid- 

time boot of the Card Executive; the Card Domain is 4Q ing a domain 310 ont0 the smart card ln the 

selected and the Security Domains from ROM are installed cxample shown in nG 6> a card issucr deploys smart cards 

using the INIT key of the Card Domain; select each Security t0 customers (step 500). A decision is made to install a 

Domain and update their keys using INIT key of the Card ven dor's application onto the issued smart card (step 502). 

Domain; select the Card Domain and load any card person- When a drogue between the issuer and the smart card is 

alization data; and select the Card Domain and install 45 ini ti ate d, a pre-signed copy of the application is forwarded 

applets, some or all of which may be in ROM. t0 lhe smart ^ (slep 504 ) M previously stated, the 

The card security architecture allows for multiple applet dialogue between the issuer and the smart card can occur via 

owners to exist on card via the use of Security Domains. A any electronic device which can interface with a smart card 

Security Domain is a logical construct that represents the and connect to an appropriate network. The application can 

aggregation of applets that are owned by a common entity or 50 be pre-signed with a key equivalent to that which already 

owner. That common owner is represented on the card by the exists on the card so that each application has a unique 

existence of a cryptographic relationship that has been signature that can be verified by the card, 

securely loaded into the card and is supported by the Card Card domain 308 can then take the steps to load the 

Domain. A Security Domain establishes and maintains a application. Card domain 308 decrypts the forwarded appli- 

chain of trust to a card, via this cryptographic relationship, 55 ca ,i 0 n and checks the signature of the application (step 508). 

for an applet owner. There may be multiple, Security Card domain 308 can decrypt the application with the 

Domains on a card with each represented by a unique issuer's secret key, An appropriate cryptography method, 

cryptographic relationship. such as Dala Encryption Standard (DES) or 3DES, can be 

The purpose of a Security Domain is to enable the post utilized to decrypt at least a portion of the application. Those 
issuance loading of applets and confidential applet data 60 skilled in the art will recognize that a number of crypto- 
using the cryptographic keys associated with that Security graphic techniques may be used to implement embodiments 
Domain. Note that the use of secure messaging during the of the present invention. For the purpose of illustration, 
post issuance load process is independent of the crypto- symmetric key techniques are addressed herein, although 
graphic functionality of the Security Domains. This crypto- asymmetric techniques are also contemplated. A good gen- 
graphic relationship includes the association of a crypto- 65 eral cryptography reference is Schneier, Applied 
graphic key with its owner and identifies specific applets or Cryptography, 2d Ed. (John Wiley, 1996), the contents of 
a range of applets that are controlled by the owner. The which are incorporated herein by reference. 
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It is then determined whether the signature on the appli- that the card is disposed of, or the applet is deleted by the 

cation is valid (step 510). If the signature associated with the cardholder or card issuer. Throughout this life cycle, the 

application is not valid, then the application is not loaded Open Platform card and its applets will transition through a 

onto the card and the process ends (step 520). If, however, number of pre-defined states. Each state that is reached will 

the signature associated with the application is valid the 5 enable the card and/or applet to perform a fixed number of 

application is then installed and available for personaliza- tasks. The Open Platform card provides a multi-applet 

lion. During personalization the application receives person- architecture for chip cards and as such must take into 

alization data (step 512). Personalization data includes data account the life cycle of the card as a whole, and the life 

which is unique to the smart card user. For instance, in a cycle of each applet contained within the card. The Card 

airline loyalty application, personalization data can include Domain is the entity on a card that is responsible for the card 

the smart card user's seating preference, meal preference, life cycle state management. 

and eligibility for various possible perquisites. This person- FIG. 7A is a flow diagram illustrating an example of card 

alization data can also be signed and encrypted. life cycle. The sequence is preferably considered irrevers- 

During personalization, cardholder and card-specific data ible. The first card state is when the smart card is Masked 

are placed on the card. This data is unique to the card and (700). During the Masked state (700), the smart card obtains, 

unique to the individual applets. Because only applets can be 15 its operating system, card identification, and preferably at 

personalized, the traditional term "card personalized" is no least one application. The Masked state (700) is achieved as 

longer appropriate for Open Platform cards. Applet person- soon as all of the necessary components for card initializa- 

alization is performed under the complete control of each tion are made available. An example of when necessary 

applet. It is the responsibility of each applet to provide components are made available is when card domain 308 

proper auditing information regarding applet life cycle state 20 and OP API 306 are enabled, as well as the Java card 

to the Card Domain including informing the Card Domain environment being enabled, such as a Java card virtual 

once personalization is complete. machine and a Java card API. During masking, the operating 

Every applet is personalized separately. Personalization system, virtual machine, class libraries and optionally, 

data is always owned by a specific applet. Personalization of applets are written into the non-mutable memory of a chip, 

an applet can begin once the applet has been registered. Each 25 After the Masked state, the next state is the Initialized 

applet receives APDU-level commands for personalization. (702) state. The Initialized state is achieved once all card 

These commands can be Update commands which the applet activity requiring an initialization key is complete. As part of 

uses to populate its field structures with the appropriate data. card initialization, if not already available, the card domain 

Each applet is responsible for determining when applet 308 application must be installed and registered. In addition, 

personalization is complete so that the applet state can be set 30 one or more security domains may also be installed and 

to "personalized." Applets implement the APDU commands registered. These installed domains must then be selected 

Set Status to finalize personalization and share the informa- and personalized. An initialization key is a secret key which 

tion appropriately with the Card Domain to allow auditing. * typically used by a smart card manufacturer during 

The following list illustrates the sequence of APDU loadin S of data onto the smart card P rior t0 i^nce. 

commands that is used when a personalization key is 35 ^ next state B Load Secured ( 704 )< The Load Secured 

involved. Personalization of an applet is started by selecting state & achieved after a secure install (post- issuance 

it with the Select command. Initialize Update is executed to download) mechanism for loading of applications through 

allow the applet to respond with the relevant derivation data lhe remainder of the card lifetime has been established, 

that has been loaded during initialization. The session key is The final card state is when the card is either expired or 

calculated based on the current personalization key. External 40 blocked (706). The blocked state is achieved as soon as an 

Authenticate is then issued to establish the appropriate level authorized smart card application has received a command 

of trust. The personalization key that is initially used by an to block the card. 

applet may have been put on the card during initialization. The card life cycle is preferably an irreversible sequence 
This personalization key may then be replaced with the of states with increasing security. Initialized and all subse- 
"real" personalization key via the Put Key command. The 45 quent card life cycle states and their transitions are prefer- 
new key data is encrypted using the current session key. ably under the control of card domain 308. Card domain 308 

Initiate is again issued resulting in a new session key executes and responds to commands that result in a transi- 

calculated based on the unique personalization key just tion in the card life cycle from one state to the next. These 

loaded previously, A new session key has been established commands are preferably Application Protocol Data Unit 

and it is used for all following personalization commands. 50 (APDU) commands. Card domain 308 is also responsible 

The final step of personalizing is the APDU command Set for the installation of applications on the card, but preferably 

Status. has no control over the applications' life cycle stales. Each 

The application then invokes card domain's 308 decryp- application is preferably responsible for its own application 

tion service for the received personalization data (step 513). life c y cle stale management but it preferably allows card 

Card domain 308 can then performs a signature check for the 55 domain 308 to have access to its life cycle states for auditing 

received personalization data (step 514). Methods of purposes. 

decrypting personalization data and performing signature The card life cycle is designed in such a way to increase 

checks are well known in the art. Finally, the application can the level of security enforced by the card at each successive 

then be activated (step 518), state. As stated above, the cycle is also established as a 

A new application which as been downloaded onto a 60 process which can only ratchet forward to ensure that once 

smart card post-issuance can be stored in a variety of ways. the card be g ins a life c y cle stale with associated security 

One example is to store the application into a file. Another policies, the only option is to cycle forward to the next state 

example is to maintain a pointer to the application object. in the lifc c y cle with a Ievel of security. The card 

domain as the system security manager of the card maintains 

CARD AND APPLET LIFE CYCLE 65 the current iif e> cyc i e slate> enforces the associated security 

The life cycle of a card and/or applet is defined as the time policies, and controls the state transitions in the card life 

the integrated circuit and/or applet is first defined, to the time cycle. 
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FIG. 7B is a flow diagram illustrating an example of an This time line starts with a Masked ROM stage 800 and 

application life cycle. The application is initially unavailable ends with a card blocked/expired stage 802. At Masked 

(750). This state is achieved as soon as an applet is deleted ROM stage 800, applications A, B, C and D are shown to be 

and/or blocked from access. The next state is a loaded state installed. This example shows applications A and B being 

(752). The application reaches the loaded state once the $ installed at a masking stage of the card, applications C and 

application has been physically loaded onto the smart card. D being installed at initialization stage, and applications E 

The application is then installed (754), and registered (756). and F being installed post issuance. 

The installed state is achieved as soon as an applet has In this example, application A can be installed in ROM 

allocated all of the necessary space and data structures for and used during the complete life of the card from Masked 

operation. The registered state is achieved as soon as an 10 ROM stage 800 to card blocked/expired stage 802. Appli- 

applet has been included in the registry of applets. Once the cation B is also in ROM and utilized during a first portion 

application is registered, it can be deleted at any time of the life of the smart card. The life of application B ends 

thereafter. The next state is the personalized state, wherein at stage 804. Application C is located in non-volatile 

personalized information is included in the application memory, such as EEPROM, which is loaded during initial- 

(758). The personalized state is achieved as soon as an applet ]5 ization. Application C is shown to expire at stage 806. 

has been updated with card holder specific data. Finally, the Application D is also located in EEPROM and is used for the 

application may expire or be blocked (760). The blocked complete life of the card until card blocked/expired stage 

state is achieved as soon as the applet makes a distinctive 802. Application E is installed at stage 808, sometime after 

call to block itself from further access. The card domain issuance of the smart card. Application E is located in 

lakes responsibility for loading, installing, registering and 20 EEPROM and used until the end of the card life at card 

deleting applets. The applet itself is responsible for handling blocked/expired stage 802. Application F is also installed 

of the applet life cycle states "personalized" and "blocked." post issuance at stage 810, and expires sometime before the 

An applet is not required to transition through all states end of the card life at stage 812. 

during its life. For example, an applet may be present on the FIG. 9 is a flow diagram of a method according to an 

card but remain dormant throughout the card lifetime 2 $ embodiment of the present invention for blocking a card. A 

because its install method is never called. The Card Domain card be can be blocked if a breach of security is detected by 

takes responsibility for and controls the loading, installation an application. According to an embodiment of the present 

and registration process of an applet until the applet is invention, a smart card can be blocked while an application 

selectable. The Card Domain keeps track of the process and is in use. A blocked card will no longer operate so that a 

can report on its status. The Card Domain does not control 30 suspect user cannot utilize any of the applications on the 

the applet life cycle states "personalized" and "blocked", smart card. Blocking is merely one example of the many 

because these applet life cycle states are under the complete functions card domain 308 can perform in managing the 

authority of the applet only. However, the Card Domain does other applications on the smart card. Examples of other 

have access to applet life cycle data for auditing purposes. functions include installing an application on the smart card, 

The life cycle of the card and its applets are determined 35 installing security domains 31 0A-310B, personalization and 

by the contents of the card memory. The smart card contains reading of card global data, managing card life cycle states 

three types of memory: persistent, non-mutable memory; including card blocking, performing auditing of a blocked 

persistent mutable memory; and non-persistent mutable card, maintaining a mapping of card applications to security 

memory. Although there are several different types of domains, and performing security domain functions for 

memory technologies currently available for each of the 40 applications which are not associated with a security 

memory types, ROM, EEPROM and RAM are the most domain. 

widely used for these respective types. This section uses In the example shown in FIG. 9, an application is cur- 

these abbreviations when referring to the memory types, but rently in use (step 600). The application detects a problem 

does not imply or mandate the use of a certain physical which triggers a card block request from the application 

memory technology. 4S (step 602). The application then sends a card block request 

The contents of the ROM are defined first. The ROM to card domain 308 (step 604). Card domain 308 determines 

contains the card operating system and may also contain whether the card block request is valid (step 606). A card 

applet code. More applets may be added during the life of block request can be valid if the request originate from a 

the card, either during the initialization and the personal- predetermined application. If the card block request is not 

ization phase, or during the post issuance phase. Loading an 50 valid, the card domain 308 does not block the smart card 

applet after the card has been issued is referred to as "Secure (step 608). However, if the card block request is valid, then 

Install". The contents of the EEPROM arc determined by a card domain 308 authorizes the card blocking (step 610), 

memory loading process that occurs after chip fabrication. and card domain 308 blocks the smart card (slep 612) such 

Therefore, the contents of the EEPROM memory, card life that the smart card will reject any attempted transactions for 

cycle and applet life cycle are closely related because of the 55 an Y of toe applications on the card, 

dynamics involved. The contents of EEPROM memory are Card blocking may be implemented as blocking of the 

modified during initialization, personalization and Secure applet Card Domain. The Card Domain applet must imple- 

Install. Although EEPROM memory contents and card state ment the specific behavior of blocking the applet itself (Card 

are closely related, there is nothing in the architecture that Domain). It must also implement the card issuer specific 

ensures that the two are synchronized. eo requirements for blocked card behavior. 

FIG. 8 is an illustration of an example of multi -application FIG. 10 is a block diagram illustrating the use of security 

card life time line. The illustration does not include any domain 310 by the card domain 308. The method and system 

off-card activities that occur prior to masking, initialization, according to an embodiment of the present invention allows 

personalization, Secure Install, nor activities that may be for multiple application providers to be represented on a 

related to card management procedures. The illustration 65 smart card in a secure and confidential manner. Th is security 

shows a card that contains six applications (A through F) and confidentiality can be achieved through the use of 

over its lifetime. security domains 310A-310B shown in FIG. 3. 
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A Security Domain in the context of the present invention ization agent receives the keys and loads security domain 

architecture is a logical construct that is implemented as an keys associated with a specific security domain 310 for each 

applet to provide security related methods to the Card smart card (1106). The card personalization agent receives 

Domain and to applets belonging to the Security Domain. smart cards and collects other data, OS, code, and applica- 

An applet provider interested in loading this application post 5 u on and card holder specific data, and places the data on the 

issuance must be represented and identified by a Security smart card (step 1108) 

Domain on the target card. There may be multiple Security ^ ^ ^ thend , the smart card l0 customers 

Domains on a card, each represented by a unique crypto- A ^ made w ^ vendof A>s 

graphic relat.onsh.p. A Security Domain applet ts respon- \ on the smart card (st m2) . when a dialogue 

sible for the management and sharing of the keys and the 10 ^ smart card issuer md ^ smaft cafd is .^J^ 

associated cryptographic methods which make up the a ^ q{ ^ , ication h forwarded t0 the smart 

domains cryptographic relationship^ An applet which is car{ f (st m4) ^ application aa be signed with a key 

loaded to the card post issuance must be associated with only . \ r , . . . f , , ■ , ,r\ . , 

rt . ^ . , . . J equivalent to that which already exists on the smart card so 

one Security Domain, however, multiple applets may be ^ each has , uni si ature that can be 

associated with the same Security Domain. Applets installed „ verified ^ card 

on a card during the pre issuance phase may optionally be ' . 

associated with a Security Domain on the card for the The smart card's card domain 308 then takes steps to load 

purpose of loading confidential data to those applets using lhe W^mon. Card domain 308 invokes an associated 

these Security Domain keys. Security Domain applets may ^""'V domain's cryptographic service to decrypt the appli- 

be included in the mask or added in initialization or per- , 0 catl0n a ? d check the signature (step 1118). It is then deter- 

sonalization. There are selectable applets which are pro- mined * lhe signature is valid (step 1120). If the signature 

tected from one another and the rest of the system via the * not valid, the process ends (step 1122). If, however, the 

standard applet security. Each Security Domain applet pro- signature is found to be valid, then the application receives 

vides an APDU interface for communication off-card and an personalization data which can be signed and optionally 

object sharing interface. „ encrypted (step 1124). The loaded application then invokes 

Tne APDU interface consists of personalization com- its associated security domain's decryption service and 

mands and is intended to allow the initial loading of Security "B™ 1 "" cne f for the r6 f ved Penalization da a (step 

~ j . 4 t - -p j • j j ■ 1126), Secret keys required to run or operate the application 

Domain keys and to support key rotation if desired during / J , M . . * yr 

*u it r .u c ** r* • tu u- . ■ ♦ f * Z on the smart card are used to activate the application by 

the life of the Security Domain. The object interface is . rr J 

comprised of the signature verification method and the 30 authentication (step UJUj. 

decryption methods which are shared with the Card Domain FIGS - 12A and l2B are flow diagrams of a method 

for post issuance loading of applets and with applets for according to another embodiment of the present invention 

decrypting application confidential data. Note that the card for providing confidential information to an application 

domain with its keys may always function as a Security using a security domain 310. The issuer decides to include 

Domain as well and does so as the default. 35 a security domain 310 on a smart card (step 1200). A trusted 

FIG. 10 illustrates an example of a smart card which party generates secret cryptographic keys and sends the keys 

contains two security domains 310A-310B. In this example, «° * card personalization agent in a secure manner (step 

it is assumed that a masked application 305A from the smart 1201). A trusted party is typically a third party who performs 

card is associated with a security domain, such as security the ^ Dctl0n of certifying the source of information, such as 

domain 310A, and an additional application 305B will be 40 a signature A card personahzation agent (which may be the 

added post issuance and be associated with a second security same as the **** ^ the _ kev an r d loads a 

domain, such as security domain 310B. The arrows indicate UDlc l ue secure domain key associated with a specific security 

key relationships between the various smart card entities as domain 310 for each smarl card < sle P 1202 > 

will now be described. Masked application 305A uses key The card personalization agent receives the smart card 

services from security domain 310A for decrypting confi- 45 and collects other data, such as OS, code, and application 

dential data and optionally for full personalization. Card a " d card holder specific data, and places the data on the 

domain 308 uses key services from security domain 3103B smart card (step 1204). The issuer then deploys the smart 

for decrypting and checking the signature of an application card to its customers (step 1206). A decision is made to 

loaded post issuance, such as post issuance loaded applica- install vendor A's application on the issued smart card (step 

tion 305B. Post issuance loaded application 305B uses key 50 1208 )- Vendor A obtains secret keys for security domain 310 

services from security domain 310B for decrypting confi- from the trusted party (step 1210). Vendor A then sends the 

dential data and optionally for full personalization. smart card issuer a signed copy of Vendor A's application 

FIGS. 11 A and 11 B are further flow diagrams of an ( sle P 1212 )- 

example for a method according to an embodiment of the When a dialogue between the smart card issuer and the 

present invention for providing an application onto an issued 55 smart card is initiated, a signed copy of the application is 

smart card. The card issuer decides to include a security forwarded to the smart card (step 1214). The application can 

domain 310 onto a smart card (step 1100). The issuer assigns be signed with a key equivalent to that which already exists 

security domain 310 to vendor A (step 1102). Vendor A, or on the smart card so that each application has a unique 

an application developer on behalf of vendor A, generates signature that can be verified by the smart card. Card domain 

cryptographic keys such as those used in symmetric or 60 308 invokes security domain's cryptographic service to 

asymmetric cryptography operations (step 1104). Examples decrypt the associated application and check its signature 

of these cryptography operations include encryption, (step 1218). It is then determined whether the signature is 

decryption, MACing, hashing, and digital signatures. valid (step 1220). If the signature is not valid, then the 

Examples of cryptographic methods which utilize such keys process ends (step 1222). 

and are suitable for implementation for the embodiment of 65 If, however, the signature is valid, then the application 

the method and system of the present invention include Data receives personalization data, which can be signed and 

Encryption Standard (DES) and 3DES. The card personal- optionally encrypted (step 1224). The loaded application 
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then invokes security domain's decryption service and sig- perform error recovery successfully, the Secure Install pro- 
nature check for the received personalization data (step cess requires the following functional support. If Secure 
1226). The cryptographic secret data required to run or Install is not completed successfully, the card operating 
operate the application on the card arc used to activate the system shall take responsibility to reestablish the original 
application (step 1230). 5 memory contents. The secure install protocol does not 

provide a mechanism for sporadic data transmission errors, 

SECURE INSTALL PROCESS EMBODIMENT e .g. single APDU repeat is not performed at the install 

The primary object of the Secure Install Process is to load protocol level, 

an applet and/or other objects from an applet server via a A number of reasons could cause a failure in the Secure 

card acceptance device and its supporting system infrastruc- 10 Install download process. These include the situations when: 

ture delivery mechanism, on to a card post issuance in a a single APDU MAC is not verified; an applet signature can 

secure and confidential manner. This process begins once the not oe verified; a memory allocation problem occurs; or a 

card issuer has converted the applet into the appropriate memory write problem occurs (physical memory error), 

install format for download. Failure during Secure Install causes a complete abort of the 

Hie applet provider can choose to sign and encrypt the 15 P race f > there ^ ore downloaded information is completely 

applet Install File. The following description assumes both erased from the card s memorv - 

encryption and signing to be required. First the Install File As indicated previously, Secure Install is implemented 

must be padded to an eight byte boundary. After padding has within the Card Domain; however, prior to the actual Secure 

been done, the Install File is encrypted using the applet Install process, a number of steps prepare, an applet before 

provided encryption key. This key is available in the corre- download. This section will provide an overview of these 

sponding Card Security Domain and will be used during the steps. The following is a description of the off card tasks that 

Secure Install process to decrypt the loaded applet. are assumed to be performed within the applet development 

Additionally, the applet provider may choose to sign the tool kit. Data entities that must be stored on the card are 

applet. The applet is signed by calculating the signature over created such as: a process method; an install method; and 

the complete Install File. If the Install File has been 25 applet data (file system and tag data). Steps required to 

encrypted, the signature is calculated using the encrypted create the install file image are the responsibility of the 

file. If the Install File has been not been encrypted, padding appropriate set of tools. The result of the download prepa- 

is to be performed before calculating the signature. The ration process s the Install File. 

signature is calculated using the applet provider Security 3Q The Install File will contain sufficient data about its own 

Domain signature key. The Card Domain Secure Install contents to allow the card operating system and/or Secure 

process uses the Security Domain key services to verify the Install to successfully install the file contents. The Install 

signature of an applet and to decrypt it. Note that neither File contents will include: the applet name (applet 

encryption nor signing are mandatory steps in the process, identifier); the applet's memory requirements; any applet 

but are policy decisions of the applet provider and the card 35 cross-linking (fix up) information; and the applet executable 

issuer. During the Secure Install Process, the signature code (process method and install method). All data objects 

service of the corresponding Security Domain is used by the (e.g. file system) to be used by an applet must be create d by 

Card Domain to verify the signature of the encrypted Install the applets install method. The file system creation must 

File. Once verified, the Card Domain may then decrypt the therefore be coded the applet provider. Populating the file 

Install File using the decryption service of the Security system with applet specific data and with card specific data 

Domain applet. In order to determine the correct Security is the responsibilty of the applet personalization process. For 

Domain, the Card Domain receives the application identifier reasons of confidentiality the applet provider may choose to 

of the applet to be loaded and its associated Security Domain encrypt the Install File. For reasons of integrity the applet 

at the beginning of the download process. The Card Domain provider may also choose to sign the Install File. The 

performs a check to validate that the application identifier is 45 signature is implemented as a symmetric key based signa- 

authorized for the proposed Security Domain on the card. ture and is verified using the applet provider's Security 

The card issuer by virtue of the Card Domain provides the Domain signature service. This signature is calculated over 

key services for the Secure Install APDU level transport the complete Install File. 

layer. Since the Secure Install process relies upon the Card The card acceptance device initiates the Secure Install 

Domain key services to provide security and integrity at the 50 process by first selecting the card's Card Domain using the 

transport level, it is the card issuer who is ultimately APDU command Select. After selecting the Card Domain, 

responsible for the transport layer. A card issuer may be authentication and the initialization of cryptographic func- 

decide upon the use of APDU encryption during Secure tions must lake place. Authentication means that the card 

Install; however use of the secure messaging during Secure responds with a cryptogram that allows the loader to verify 

Install is mandatory. 55 the card identity. Initializing the cryptographic functions 

The card issuer uses the Card Domain to provide integrity means that the smart card as well as the loader must 
and confidentiality during Secure Install by means of DES calculate session keys. The APDU command used is the 
based cryptographic methods. At the APDU level secure Initialized Update command. When this command is 
messaging is used to verify that all data of an APDU received, the Card Domain shall calculate the session keys 
transmission has been received correctly and unmodified, go for the APDU MAC verification and for the APDU data 
and to insure the confidentiality of data. Secure messaging decryption. The Card Domain shall create a response con- 
can be performed as described in the specification Visa sisting of a cryptogram for authentication purposes and key 
Integrated Circuit Card,Specificalion Version 1.3. diversification data, Following this response, the Card 

The Card Domain Secure Install process offers full error Domain Secure Install process is now ready to receive the 

recovery that is independent of the processing stage reached 65 Install File on the card. 

during a Secure Install section. Either the Secure Install Successful completion of the previous command is a 

succeeds completely or is not performed at all. In order to prerequisite for the Install File transmission. Transmitting 
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(loading) the Install File is initiated by the APDU Install input to tho initialization procedure (pre issuance load); and 

command. After successful completion of this command, the distribution for post issuance load (Secure Install). The 

Install File Loading can be performed using the APDU Load Install File format and its contents are target system inde- 

Install File command. pendent. The result of an applet development process is a 

For signature checking and Install File decryption the 5 target system independent signed Install File that contains 

Card Domain will use the key services supplied by the tne complete information need for loading an applet onto a 

corresponding Security Domain. Signature checking and card ^ a PP lel executable is contained within a single 

Install File decryption is initiated using the Install command. Install File. This Install File can be used for any of the 

After a successful verification of the applet signature and following: the masking process; the initialization process; or 

decryption of its executable, the Card Domain must now call ™ the Secure Install process, 
the applet's install method; allocate memory for its data 

objects; configure data sharing for the applet; and register CRYPTOGRAPH KEYS FOR POST ISSUANCE 

the applet with the Card Domain. As soon as the applet LOADING 

install method has completed successful, the applet is inte- Key management relies on a hierarchy of keys. Keys 

grated into the card environment as follows. The applet 15 highef up in ^ hierarchy are used to securely load addi- 

application identifier is registered in the list of selectable lional keys int0 the card means that {he highest key in 

applets and the card auditing information is updated. Reg- lne hierarchy is an initial key. At the IC level there is a chip 

istering an applet makes the applet selectable. Only a password and an initialization key. At the next level below, 

registered applet can receive APDU commands for process- the Security Domain level, there are Security Domain keys, 

ing. After integrating the applet into the card environment, 20 At (he next application level there ^ an application person- 

the applet must be personalized. The data objects (e.g. file alization key and application transaction keys. Finally, down 

system) themselves have been created by the applet's install al the sess j on leve^ there are applications session keys. Note 

method. The process is identical to an applet personalization lhal the Card Domain functions as the default Security 

process. Domain on the card, thus the Security Domain level noted 

The contents of the applet Install File are not only the 25 above includes the card Domain keys. Security Domain keys 
applet itself, but also information required by the load may have a hierarchical relationship with the initialization 
process. Therefore the Install File contains: the actual applet key or with the card domain keys depending on the require- 
class, the mandatory data required to perform the download; ments of the Security Domain owner, 
and the optional data to aid the download process and to ^ Th e initialization key is available when the card initial- 
improve its performance. ization procedure is authorized. It is used as an encryption 

The applet Install File must contain all information that is key to confidentially load secrets, e.g. other keys, onto the 

required by the card in order to receive the applet, store it in card and is initially owned by the Card Domain. The 

non volatile storage and make it ready to run. This manda- initialization key is used for the encryption of APDU data 

tory data includes the following: name or identifier of the 35 during initialization and the decryption of Security Domain 

applet; identification of hardware and software requirements and encryption keys. A Security Domain and encryption key 

(version of virtual machine, system class and system is a special dedicated version of an encryption key. Each 

framework); link references to libraries and classes in ROM Security Domain has an encryption key and a signature key. 

that need to be resolved; link references to libraries/class/ The encryption key is used to decrypt the Install File during 

functions in non volatile that need to resolved; link refer- 4Q post issuance applet loading and to decrypt the applet 

ences within the applet lhal need to be resolved; fix ups for personalization key. 

data references that need to be resolved; entry points for The Security Domain signature key is a special dedicated 

"process" and "install" methods; and proof of ownership, version of a MAC key. Each Security Domain has a signa- 

origin, and completeness and correctness. Optional infor- ture key and in one implementation the signature is repre- 

mation includes memory requirements, debug information 4J by a MAC MAC key is used l0 verify lhe InslalI 

and any potential terminal related information. py e signature during post issuance applet loading. The 

The applet development process begins as soon as a application personalization key is used during applet per- 

concept of the desired applet is formulated. Once son a lizat ion and is owned by the applet. The key is used to 

formulated, the concept must go through a number of stages load card and or applet specific data (which can also be keys) 

before becoming a full fledged working and installable 50 into the applet. An application encryption key is used lo 

applet. An applet consists of two primary elements; the encrypt and decrypt data, for example, it can be used lo 

applet's process method; and lhe applet's install method. encrypt APDU data. Encryption keys are owned by applets 

The applet development process (executable) is considered and have applet specific uses. Encryption keys are used to 

complete after creating and securely delivering the Install decrypt APDU command data and to encrypt APDU 

File. This development process may vary by organization 55 response data. An application MAC key is used to create or 

but in general consists of the following steps: applet require- to verify a MAC. The keys arc owned by applets, 

ments gathering and definition; applet specification is devel- i n or der to load keys of a specific Security Domain applet, 

oped from requirements; source code is developed from the Security Domain applet has to be selected. The Security 

specification; managing applet source code, testing, approv- Domain encryption key may be encrypted with the Card 

ing; translate applet source code into card executable code; 60 Domain initialization key or optionally with the Card 

conversion to card byte code; card byte code verification; Domain encryption key if initialization had ended. The 

code linking and reference resolution; and signature ere- Security Domain encryption key is used to encrypt the 

ation. Security Domain signature key. Security Domain signatures 

The results of the translation process is the Install File. must be loaded encrypted using the encryption key of the 

The Install File contains the card byte code that is to be 65 corresponding security domain. It is not required to perform 

executed by the card. The purpose of this file may be one or this function during initialization, it is only required to be 

more of the following: input to the ROM image (masking); performed before any Secure Install. The above completes 
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the loading of keys into one or more Security Domains. The application has been loaded onto the smart card. If a security 
Security Domain encryption key service is shared to corre- domain 310 is not associated with the newly loaded 
sponding applets for decryption of confidential applet data. application, then card domain 308 performs security 
The key services of the Security Domains are also shared domain's 310 functions. Once the new application is post- 
with the Card Domain for Secure Install. In order to load 5 issuance downloaded, various keys such as a cryptographic 
confidential data (including keys), an applet can use decryp- key and a signature key are preferably utilized for installa- 
tion services of it's corresponding Security Domain. The tion and personalization of the application. 
Card Domain acts as the default Security Domain. 

HO. 13 is a block diagram illustrating tbe use of cryp- APPLET lNS^LL COMMANDS 

tographic keys for post issuance loading of an application 30 bMBUUlMfcN 

onto a smart card. Applications that are not masked and not This section describes the APDU command response pairs 

loaded during card initialization stage or personalization use d in the pre issuance and post issuance applet load and 

stage need their executables downloaded using a secure install of Open Platform compliant chip cards. The follow- 

installation method, such as the post issuance download ing APDU command response pairs are defined and shall be 

described in the previous figures. The applications can be 15 supported by the Open Platform Card Domain, 

loaded using the card domain cryptographic keys. The Securit requirements may vary from one Applel Ij0ad/ 

applications are then decrypted and can have their signature Install t0 aQOlher ^ tw0 securi aIteraalives offered in the 

verified using the key services of the corresponding security specificalion for server authentication by the card shall be 

domain 310. Therefore, the desired security domain(s) 310 supported by the Open Platform Card Domain. At the 

preferably have encryption and signature keys installed prior 20 ^ ^ fc authenticated Qncc at the b in _ 

to the post issuance download of the corresponding apph- ning of thc session (usage of External Authenticate 

catl0D * command). At the command level, the server is authenti- 

In the example shown in FIG. 13, only one security C ated at the unitary APDU command (usage of APDU 

domain 310 is shown since security domains 310 for other command MACing). Security requirements typically differ 

applications are not relevant to illustrate the downloading of 25 between pre issuance and post issuance sessions. For 

a single application. Note that the result of the secure example, pre issuance (identified by the Card life Cycle 

installation is initially a loaded application, which must then status set to "Masked" or "Initialized") server authentication 

be installed, registered and personalized. After loading, the ^ a t the session level. At post issuance (identified by the 

application is installed, preferably by issuing an install Card Life Cycle Status set to "Personalized") server authen- 

APDU command to card domain 308. An application can be tication is at the command level. The card authentication by 

installed when its install method has executed successfully. the server is only offered at the session level (usage of 

Memory allocations have been performed by the time an Initialized Update command). 

application is in an install state. A loaded application should 11le Sekct command j s f or selecting the Card 

also be registered. When an application is registered, it is Do main. The Card Domain may be selected either for 

selectable and it is ready to process and respond to APDU loading a new applet (or Security Domain) or installing a 

commands. Installation and registration may be performed previously loaded applet (or Security Domain). The Select 

simultaneously by the same APDU command. An applica- command message includes the length of the AID and the 

tion is also personalized after loading. A personalized appli- Card Doma in AID. The data field of the response message 

cation includes cardholder specific data and other required conlains the fi!e control information (FC I) specific to a Card 

data which allows the application to run. Domain. The FCI returned by a successful selection includes 

To allow personalization to be performed, the applet uses an FCI template, a Card Domain name, proprietary data, 

services of the security domain to load confidential data. The applet production life cycle, maximum block length, and 

personalization key can be considered to be the confidential FCI discretionary data. 

data. Note that all post issuance "PUT— KEY" commands 45 An « applet invalidated" warning condition may be 

must be MACed and encrypted. Further processing now returned by the integrated circuit card (ICC). This is a case 

requires the applet to be selected. After selecting the applet where the card ^ blocked. Blocking the card results in that 

any additional applel keys may be loaded using the person- Card Domain may still be selected with this warning 

alization key for encryption. Here the applet specific per- condition, while any other applet present on the card may 

sonalization rules may be applied. 5Q not ^ selected any more and shall return the error condition 

In the example shown in FIG. 13, the cryptographic key "applet not found". The following error conditions may be 

and MAC/Signalure key are shown to be included in the returned by the ICC: no precise diagnosis, wrong length, 

functions of card domain 308/security domain 310. If a applet not found, incorrect PI P2. 

security domain is associated with the application being The Initialize Update command is used to retrieve infor- 

loaded, then the security domain will be invoked. However, 55 ma tion data on the integrated circuit card key to be used for 

if no security domain 310 is associated with the application the current session and to obtain from the ICC some unique 

which is being loaded, then the cryptographic key and thc session data. It also initiates the computation by the card of 

signature key of card domain 308 will be utilized. In contrast a umque session key and the encryption of a given challenge 

to the install commands sent to the smart card during the f rom the server to thc ICC using this session key. The 

initialization phase, the post issuance install command is not 60 response from the ICC consists of returning to the server 

issued in a secured environment, therefore it is preferably so me information valid for the session, i.e., key diversifi- 

protected with a cryptographic key, such as a MAC/ cat i 0 n data (card unique data), key information (key and 

Signature key. Note that the install does not populate key algorithm references), session unique data (ICC challenge to 

space, but only allocates key space within an applet. the server), and a cryptogram. The server may verify the 

Card domain 308 manages the post-issuance loading of a 65 cryptogram, i.e. authenticate the ICC, prior to start the 

new application, while security domain 310 ensures the load/install process. A previous and successful execution of 

validity and integrity of the new application once the new the Select command is required before processing the Ini- 
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tialize Update command. A success execution of the Initial- the authorized method of the identified Security Domain 
ize Update command is required before processing an Install with the new applet (or Security Domain) AID. It instructs 
command. the Card Domain to accept one or m ore subsequent Lo ad 
The data field of the response message contains the Applet comma nd s only after the authorized method has 
following data elements: key diversification data, key infor- 5 been successfully executed. The Card Domain should auto- 
mation data, card challenge to server, and cryptogram. The matically link the new applet (or Security Domain) after the 
following error conditions may be returned by the ICC: no successful execution of the last Load Applet command. It 
specific diagnosis, wrong length, conditions of use not shall not automatically invoke the install method of the 
satisfied, function not supported (which is the case when the loaded a PP lel ( or Security Domain) after the last Load 
card is blocked), and incorrect PI P2. 10 Applet command. If the original Applet Life Cycle Status is 

The External Authenticate command asks the currently " n ° l available "' an error condition * returned b * 
selected applet in the ICC, here Card Domain, to verify a 

cryptogram. The cryptogram is computed by encrypting the T° e bit combination 0100 applies to a previously loaded 

card challenge to the server returned in the Initialize Update applet (or Security Domain. It instructs the Card Domain to 

response message using a single DES algorithm in ECB 15 invoke the install method of the identified applet (or Security 

mode with the current session key. A previous and successful Domain) with the install parameters present in the Install 

execution of the Initialize Update command is required command data field. If the Original Life Cycle Status is 

before processing the External Authenticate command. The otner tDan "loaded" an error condition shall be returned by 

successful authentication of the server is required prior to tDe ICC - A fo ture release will support a combined load and 

the execution of any Install or Load command without 20 installation of a new applet (or Security Domain). 

Macing. In other words, during pre issuance load/install The security control parameter of the Install command 

server authentication is required algorithms, includes the following meanings: RFU; checksum; decrypt; 

The External Authenticate command includes in a data a nd check signature. Regarding checksum, a future release 

field a cryptogram to verify. The key and algorithm refer- 25 wil1 support this bit instructing the Card Domain to invoke 

ences used to compute the cryptogram are known by the ICC 2 tQ e checksum method. When loading a new applet (or 

un ambiguously, i.e., the session key and the algorithm Security Domain) as indicated in the reference control 

identified in the Initialize Update response. An "Authenti- parameter bits 1 to 3 allow cryptographic controls over the 

cation Failed" warning condition may be returned by the load/install process. The following bit combinations are 

ICC. The following error conditions may be returned by the va li d - T° e bit combination 001 applies to a new applet (or 

ICC: no specific diagnosis; wrong length; authentication Security Domain). It instructs the Card Domain to invoke 

method blocked; conditions of use not satisfied; or incorrect tne check signature method of the identified Security 

PI P2. Installing an applet or Security Do main needs the Domain with the applet (or Security Domain) AID after the 

execution of different functions according to methods successful execution of the last Load Applet command. The 

invoked by the Card Domain (e.g. install method, check „ bit combination 010 applies to a new or previously Loaded 

signature). The Install command instructs the Card Domain Applet (or Security Domain). It instructs the Card Domain 

on which installation step it shall perform. A previous and to invoke the decrypt method of the identified Security 

successful execution of the Initialize Update command is Domain with the applet (or Security Domain) AID after the 

required before processing the Install command. MACing is successful execution of the last Load Applet command, 

required for this command when a previous External 4Q The bit combination 011 Applies to a new or previous 

Authenticate command has not been successfully executed. Loaded Applet (or Security Domain). It instructs the Card 

The Install command message includes a reference control Domain to invoke the check signature and decrypt methods 

parameter, a security control parameter, length of the data of the identified Security Domain with the applet (or Secu- 

field, data and MAC (if present). The reference control rity Domain) AID. The check signature method shall be 

parameter of the Install command is coded to indicate the 45 revoked after the successful execution of the last Load 

following meanings: RFU, register, install, load, and autho- Applet command. The decrypt method shall be automati- 

rized. Regarding the register meaning, a future release may cally revoked only after the check signature method has 

support this bit instructing the Card Domain to register a been successfully executed. The data field of the Install 

new applet (or Security Domain) into a specific security command message contains the following data elements: 

Domain. In the current release, any installed applet (or 5Q applet identifier length indicator; AID; Security Domain 

Security Domain) is automatically registered in the Card identifier length indicator; Security Domain identifier; 

Domain. install parameters length indicator; install parameters; and 

Bits 1 to 4 of the reference control parameter control the MAC. 

sequencing of the load/install process. The following bit The following error conditions may be returned by the 

combinations are valid. The combination 0010 applies to a 55 ICC: no specific diagnosis, security status not satisfied, 

new applet (or Security Domain). It instructs the Card conditions of use not satisfied, secure messaging data object 

Domain to accept one or more subsequent Load Applet missing, secure messaging data object incorrect, incorrect 

commands. The Card Domain shall automatically link the PI P2, invalid Life Cycle State, authorization failed, applet 

new applet or Security Domain (byte code) after the sue- load failed, signature check failed, decryption failed, check- 

cessful execution of the last Load Applet command. It shall 60 sum failed, installation failed, or registration failed, 

not automatically invoke the install method of the Loaded This section defines the byte code block structure as 

Applet (or Security Domain) after the last Load Applet transmitted in the load Applet command data field for 

command. If the original Applet Life Cycle Status is other loading an applet (or Security Domain). The Load Applet 

than "not available" an error condition shall be returned by command loads one byte code block at the time. Byte code 

the ICC. 65 blocks are numbered. The first byte code block shall be 

The bit combination 0011 applies lo a new applet (or numbered 00. The blocked number shall be strictly sequen- 

Security Domain). It instructs the Card Domain to invoke tial and incremented by one. The card shall be informed of 
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the last block. After receiving the last block, the card shall setting the card cycle life status. It instructs the card domain 

execute the internal process, if any, identified in the security to increment the state of the card life cycle status. If the Card 

control parameter of the previous Install command. A pre- Domain is not the currently selected environment, an error 

vious and successful execution of the Install command with condition shall be returned by the ICC. In this case, the 

its reference control parameter instructing a load is required 5 following combinations for bits of the state parameter of the 

before processing the Load Applet command. MACing is Set Status command are valid. Bit combination 001 sets card 

required for this command when a previous External ,lfe c y c,e stalus f r rom M , asked 10 IniUahze. Bit combination 

Authenticgate command has not been successful executed. I 00 * te ™? hfe F^c s f™ from In * a ^d to Load 

In other words, MACing is not required during pre issuance Secured. If the original card life cycle status is other than 

Masked or Initialized, an error condition shall be returned by 

load/install. 10 , . . , . . . , _ , * 

^ , , , ... the ICC. Blocking the card is ensured using the Card Block 

Hie load applet command message includes a reference command< A blocked card not ^ unb locked. 

control parameter block number, ength of the block, and combination 01 of the reference control parameter 

byte code block. Rie data field of the command message - . . 4l . f . . . t. • . . .l 

J . . , , , , . . 1C XMA „ . ..Li applies for setting the applet life cycle status. It instructs the 

contains the byte code block. If a MAC is present, the key «i i ♦ 3 i . . ■ ♦ ** * ♦ t* i . 

, . . lL J c j , f , l n currently selected applet to mcrement its state. If an applet 

and algorithm references used to compute it are known by 13 . . ' .i i . j i . j *- £ n 

*l ir^% i • * • ■ . , j i -.u is not the currently selected applet, an error condition shall 

the ICC unambiguously, i.e., the session key and algorithm . . , , .l too i *l- *l c n l- 

•a .-c a • .l i v a it a . be returned by the ICC. In this case, the following combi- 

ldentified in the Initialized Update response. . - c t . t4 . . ... 6 

r v nation for bits of the state parameter is valid. Bit combina- 

The following error conditions may be returned by the tion 100 set5 Applet Life Cycle Slatus from Registered l0 

ICC: no specific diagnosis, memory failure, security status Personalized. If the Original Life Cycle Status is other than 

not satisfied, conditions of use not satisfied, secure messag- Registered, an error condition shall be returned by the ICC. 

ing data object missing, secure messaging data object flowing state transitions are automatically managed 

incorrect, not enough memory space, invalid block number, by lhe Card Domam dur i og t h e Load/Install process and not 

applet load failed, signature check failed, decryption failed, by the Set Status co mmand ; from Not Available to Loaded, 

or check sum failed. ^ from Lo adedj f rom Loaded to Installed, from Installed to 

APDU INITIALIZATION AND Registered. Blocking an applet is insured using the Applet 

PERSONALIZATION COMMANDS Block command - Unblocking an applet is insured using the 

EMBODIMENT Applet Unblock command. In a future release, the applet 

installer will allow applet deletion and will manage auto- 

This section describes the APDU command response pairs 3Q matically the state transitions to Not Available, 

used for pre issuance and post Issuance initialization, per- Thc following error conditions may be returned by the. 

sonalization and audit of Open Platform compliant chip \QC: no precise diagnosis, memory failure, security status 

cards. The following APDU command response pairs are nol salis fied, conditions of use not satisfied, secure messag- 

defined: Get Data, Set Status, Select, Initialize Update, mg dala object missing, secure messaging data object 

External Authenticate, Put Key, Update Record, Update 35 i ncor rect, incorrect PI P2, or invalid life cycle state. 

Binary, Put Data, Pin Change/Unblock, and Update Param- The Sdect command selects the ICC appIel correspond- 

eter> ing to the submitted AID, i.e., an Applet, Card Domain, or 

Security requirements are applet specific. Two security Security Domain. The response from the ICC consists of 

alternatives arc offered in this specification for server returning the Applet, Card Domain or Security Domain file 

authentication by the card. At the session level, the server is 40 control information (FCI). The data field of the command 

authenticated once at the beginning of the session (usage of message contains the AID of the Applet, Card Domain or 

External Authenticate command). At the command level, the Security Domain. The data field of the response message 

server is authenticated at the unitary APDU command contains the FCI specific to the Applet Card Domain or 

(usage of APDU command MACing). Two security alter- Security Domain. The warning condition "applet invali- 

natives are also offered in this specification for card authen- 45 dated" may be returned by the ICC. This is the case where 

tication by he server. At the section level, the card is lne applet is present by is blocked. The following error 

authenticated once at the beginning of the session (usage of conditions may be return by the ICC: no precise diagnosis, 

Initialize Update command). At the command level, the card wrong length, function not supported (this is a case where 

is authenticated at the unitary APDU command (usage of tn e applet is present but the card is blocked), applet not 

Update Parameter response MACing), These different secu- 50 f oun d (this is a case where the applet does not exist in the 

rity mechanisms may be combined during a session. An ice or is present but not yet installed) or incorrect PI P2. 

applet may also require different security mechanisms dur- llie initialize Update command is used to retrieve infor- 

ing the card life such as a stricter security at post issuance mation dala on the ICC key t0 be used for the currenl session 

then at pre issuance. and t0 obtain from the ICC some unique session data. It may 

Thc Get Data command is used to retrieve data objects 55 initiate the computation by the card of a unique section key. 

such as: card production life cycle data, card life cycle It may also initiate the encryption of a given challenge from 

status, applet life cycle status, applet personalization key the server to the ICC using -he unique session key. The 

information, or applet production life cycle data of the response from thc ICC consists of returning to the server 

currently select applet. some information valid for thc session such as: key diver- 

The Set Status command is used for incrementing the life 60 sification data (card unique data), key information (key and 

cycle status data of the card or the currently selected applets. algorithm references), session unique data, arid optionally a 

The state parameter of the Set Status command message cryptogram. The server may verify the cryptogram i.e., 

includes the following meanings: applet personalized/card authenticate the ICC, prior to the start of the personalization 

load secured and initialized. The reference control parameter process. A previous and successful execution of the Select 

of the Set Status command includes the following meanings: 65 command is required before processing the Initialize Update 

card life cycle status, and applet life status. The bit combi- command. The reference of the key is known by the ICC 

nation 10 for the reference control parameter applies for unambiguously. Any other value uniquely identifies the key 
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index within the key set identified in the command message 
data field. The key index in conjunction with the key set 
identifier uniquely identifies the key and the algorithm to be 
used: both references arc only applicable to the current 
context, i.e. the currently selected Applet, Card Domain or 
Security Domain. When a bit of the reference control 
parameter is set, the data field of the command message is 
applet specific and typically contains server session data 
including some or all of the following data elements: key set 
identifier, challenge to ICC. 

The External Authenticate command will ask the cur- 
rently selected applet in the ICC to verify a cryptogram. The 
cryptogram is computed by encrypting the card session 
unique data returned in the Initialize Update response mes- 
sage with a unique per card applet (or Unique per session) 
key. A previous and successful execution of the Initialize 
Update command is required before processing the External 
Authenticate command. The key and algorithm references 
used to compute the cryptogram are known by the ICC 
explicitly, e.g., the ones identified in the initialized update to 
response. The data field of the command message contains 
the cryptogram to verify. The warning condition "authenti- 
cation failed" may be returned by the ICC. The following 
error conditions may be returned by the ICC: no specific 
diagnosis, wrong length, authentication blocked, conditions 
of use no satisfied or incorrect PI P2. 

The Put Key command is used to store or replace a key set 
(containing one or more keys) or a specific key within a key 
set with the data provided in the command data field. When 
already existing in the ICC, the current key set or specific 
key shall be replaced. A key is identified by a key index 
within a key set and a key set is identified by a key set 
identifier: both references are only applicable to the current 
context, i.e., the currently selected Applet, Card Domain or 
Security Domain. The value P2 or the Put Key command 
message shall be set to 00 when more than one key is 
transmitted to the ICC. P2 shall indicate the key index when 
a single key is transmitted to the ICC. The key index in 
conjunction with the reference to the key set of the currently 
selected applet (or Card Domain or Security Domain) 
uniquely identifies the key to be stored/replaced. 

The reference control parameter indicates if the command 
data field contains one or more keys. If the command data 
field contains multiple keys it is coded according to the 
following structure, including the identification of empty 
key set entries and the end key set delimiter: a key set 
identifier is followed by pairs of key indexes, each key index 
has an algorithm identifier and a key data field. 

When the command data field contains only one key (of 
which the key index is given in P2), it is coded according to 
the following structure: a key set identifier is followed by an 
algorithm identifier and a key data field. 

Depending on the buffering capability of the ICC for both 
APDU reception and data decryption, transmitting the keys 
to the ICC may require one or more command messages. A 
bit of the reference control parameter indicates if (at least) 
one subsequent command message shall be expected. When 
the bit is set, the current APDU is the last (or only) one. 
When the bit is reset, a subsequent APDU shall be expected 
and shall refer to the same key index if the current parameter 
P2 is not set to zero. This case is particular applicable to 
large keys such as RSA, If parameter P2 of the subsequent 
APDU is different from the previous one, an error condition 
shall be return by the ICC. 

The command message data field contains (part of) an 
encrypted key set structure. The entire key set structure (i.e., 


the key set identifier and key set entries) shall be encrypted. 
When replacing multiple existing keys, the new key set shall 
be presented with the same number or keys and the same 
length for each key as it exists within the card. When 
5 replacing a single existing key, the new key shall be pre- 
sented with the same length as it exists with the card. A 
future release will support replacement of a key set with a 
different number of keys and keys with different lengths. If 
the algorithm identified in the algorithm identifier is not 
10 supported, an error condition shall be returned by the ICC. 
The reference of the encrypting key and algorithm to be used 
are known implicitly by the ICC according to the current 
context i.e., the current selected Applet, Card Domain or 
Security Domain. If a MAC is present, the key and algorithm 
15 references used to compute it are known by the ICC implic- 
itly e.g. the ones identified in the initialize update response. 

The data field of the response message contains in clear 
text the key set identifier followed by the key check values 
presented to the ICC encrypted in the command. These 
20 returned key set identifier and key check values may be used 
by the personalization server to verify the correct decryption 
by the ICC of the encrypted key set. In other words, this may 
be used by the server for validating key personalization/ 
update. The following error conditions may be returned by 
25 the ICC: no specific diagnosis, memory failure, wrong 
length, security states not satisfied, conditions of use not 
satisfied, secure data object missing, secure messaging data 
object incorrect, incorrect parameters in the data field, not 
enough memory space, incorrect PI P2, referenced data not 
30 found, algorithm not supported, or invalid key check value. 
A future release will support ICC internal verification of key 
check value before key personalization update. 

The Update Record command is used to store or replace 
a record in a linear or cyclic file with the data provided in the 
35 command data field. Here it is assumed that before 
personalization, the Applet (or Security Domain) install 
process includes both the creation of all the required linear 
and cyclic files with the appropriate format, number of 
records, and access conditions and the creation of all the 
required records of fixed or variable length. If the applet 
install process only creates the files but not records, the 
Append Record command shall be used. When already 
existing in the ICC, the current record shall be replaced. The 
Update Record command record message includes a record 
number to be updated, a reference control parameter, a 
length of the record data, and the record data. 

The data field of the command message contains the new 
record data in clear text. A future release will support 
5Q personalization of records presented encrypted to the ICC. If 
the record already exists, the new data is presented in the 
same format (including the record template tag and length 
when defined) and with the same length as it exists within 
the current record in the card. If a MAC is present, the key 
ss and algorithm references used to compute it are known by 
the ICC explicitly, e.g., the ones identified in the initialize 
update response. 

The following error conditions may be returned by the 
ICC: no specific diagnosis, memory failure, wrong length, 
60 command incompatible with file structure, security status 
not satisfied, condition of use not satisfied, secure messaging 
data object missing, secure messaging data object incorrect, 
file not found, record not found, or incorrect PI P2. 
The Append Record command is used to store (but not 
65 replace) a single record as a new record at the end of a linear 
file or at the beginning of a cyclic file with the data provided 
within the command data field. Here it is assumed that 


40 
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before personalization, the Applet (or Security Domain) 
install process includes the creation of all the required linear 
and cyclic files with the appropriate format, number of 
records and access conditions but does not include the 
creation of the records; themselves. If the install process 5 
creates all the required records the update record command 
shall be used. On a successful execution of the command, 
the ICC increments the record numbering of the file. The 
first record of a file is numbered 01. 

The Append Record message includes a reference control 10 
parameter, length of record data and the record data. The 
data field of the command message contains the new record 
data in clear text. A future release will support personaliza- 
tion of records presented encrypted to the ICC. The entire 
record data will be encrypted as a unit. If a MAC is present, 35 
the key and algorithm references used to compute it are 
known by the ICC explicitly, e.g., the ones identified in the 
Initialize Update response. 

The Update Binary command message includes a refer- 
ence control parameter, a binary offset from the beginning of 2 o 
the file, length of the binary data and the binary data. The 
data field of the command message contains new binary data 
in clear text. A future release will support personalization of 
transparent files presented encrypted to the ICC. The entire 
sequence of binary data will be encrypted as a unit. If 25 
already existing, the new binary data is presented with the 
same format and length as it exists within the current file in 
the card. If a MAC is present, the key and algorithm 
references used to compute it are known by the ICC 
explicitly, e.g., the ones, identified in the Initialize Update 30 
response. 

The Put Data command message includes a data object 
tag. The data field of the command message contains in clear 
text the new data objects, A future release will support 
personalization of TLV coded data objects presented 35 
encrypted to the ICC. If already existing, the new data 
objects will be presented with the same format and length as 
it exists within the card. A future release will support 
replacement of data objects with different lengths. If a MAC 
is present, the key and algorithm references used to compute 40 
it are known by the ICC explicitly, e.g., the ones identified 
in the Initialize Update response. The following errors may 
be returned by the ICC: no specific diagnosis, memory 
failure, wrong length, security status; not satisfied, condi- 
tions of use not satisfied, secure messaging data missing, 45 
secure messaging data object incorrect, incorrect parameters 
in the data field, not enough memory space, incorrect PI P2, 
or data object not found. 

The PIN Change/Unblock command is used to store or 
place a PIN value and reset the associated PIN try counter 50 
to the value of the PIN try limit within the currently selected 
applet. When already existing in the ICC, the current PIN 
shall be replaced. The PIN-Change/Unblock command mes- 
sage includes a reference control parameter, a length of PIN, 
and the encrypted PIN. The data field of the command 55 
message contains the encrypted PIN value. If already 
existing, the new PIN shall be presented with the same 
format and length as it exists within the card. A future release 
will support replacement with a PIN of a different length. 
When resetting the PIN try-counter, if the PIN try-limit data 60 
does not exist, an error condition shall be returned by the 
ICC. The reference of the encrypting key and the algorithm 
to be used are known implicitly by the ICC according to the 
current context, that is typically triple DES algorithm in 
ECB mode with double length applet personalization (or 65 
update) key. If a MAC is present, the key and algorithm 
references used to compute it are known by the ICC 
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unambiguously, e.g. the ones identified in the Initialize 
Update response. 

The following error conditions may be returned by the 
ICC; no specific diagnosis, memory failure, wrong length, 
security status not satisfied, conditions of use not satisfied, 
secure messaging data object missing, secure messaging 
data object incorrect, incorrect parameters in the data field, 
not enough memory space, incorrect PI P2, or reference data 
not found. 

The Update Parameter command is used to store or 
replace one or more: tagged data objects provided in the 
command data field. It also returns to the server a crypto- 
graphic proof of its execution. When already existing in the 
ICC, the current data objects shall be replaced. The reference 
control parameter of the update parameter command mes- 
sage includes the following meanings; coding according to 
this specification, clear text data field, and encrypted data 
field. 

The data field of the command message contains a chal- 
lenge to the ICC from the server followed by the new data 
objects. When a bit of the reference control parameter is 
reset, the new data objects are presented to the ICC in clear 
text. When a bit of the reference control parameter is set, the 
new data objects are presented to the ICC encrypted. The 
entire sequence of (one or more) TLV coded data objects, 
including tags and lengths, will be encrypted as a unit, 
without any padding of the individual data objects. 

Security related command messages (e.g. Initialized 
Update, Put Key) refer to algorithms and keys in the ICC. 
The reference may be explicit or implicit. This section 
defines the key set structure as transmitted in the Put Key 
command data field. It does not define the ICC internal 
handling or storage of keys. 

A specific key is associated with one and only one 
algorithm. The algorithm-key pair is defined as a key set 
entry in a key set. Identifying a key set entry and a key set 
allows for explicitly referencing an algorithm/key pair (e.g. 
MAC verification, using triple DES in CBC mode with a 
double key length). Such referencing prevents from misus- 
ing keys or algorithms. A key set is a table algorithm and key 
pairs valid for the execution of a security related command. 
A key set may contain one or more algorithm/key pairs. A 
key set identifier identifies the key set within the current 
context, i.e. the currently selected applet. In other words, the 
key set identifier value is relative to the current applet. This 
implies that a similar value for a key set identifier may be 
used by different applets. Different key set identifiers are 
used to differentiate different key versions. 

A key set contains a variable number key set entries. A key 
set entry is an algorithm/key pair valid for the execution of 
a security related command. A key index identifies the key 
set entry of the key set identified in the current context, i.e. 
the currently selected applet. In other words, the key index 
value is relative to the current key set. This implies that a 
similar value for a key index may be used by different key 
sets within a single applet. The first entry of a key set is 
referred to as the Key Index 01. Different key indexes within 
one key set may be used to differentiate different key usage 
and function. Each key set entry is divided into two parts, 
namely the algorithm identifier and the key data field. The 
algorithm identifier is coded on one byte according to a table 
and includes the following meanings; DES-ECB mode, 
DES-CBC mode, symmetric algorithm, RSA public key, 
RSA private key, RSA private key-Chinese remainder, and 
asymmetric algorithms. 

A method and system for a smart card domain and a 
security domain has been disclosed. Software written 
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according to the present invention may be stored in some 
form of computer-readable medium, such as memory or 
CD-ROM, or transmitted over a network, and executed by a 
processor. Although the present invention has been 
described in accordance with the embodiment shown, one of 
ordinary skill in the art will readily recognize that there 
could be variations to the embodiment and these variations 
would be within the spirit and scope of the present invention. 
Accordingly, many modifications may be made by one of 
ordinary skill in the art without departing from the spirit and 
scope of the appended claims. 
What is claimed is: 

1. A method for loading a smart card application onto a 
smart card after said smart card has been issued to a 
cardholder, said method comprising: 

issuing said smart card to a cardholder, said smart card 
including a card domain application arranged to man- 
age the post-issuance loading of applications; 

establishing communication between said smart card and 
a provider of said smart card application; 

loading said smart card application onto said smart card 
under control of said card domain application; and 

checking a cryptographic signature of said smart card 
application using said card domain application, 
whereby said smart card application is loaded onto said 
smart card post -issuance in a secure manner. 

2. A method as recited in claim 1 further comprising: 
providing a cryptographic signature key to said card 

domain application before said smart card application 
is loaded onto said smart card; 
signing said smart card application using said crypto-' 
graphic signature before said smart card application is 
loaded onto said smart card, said cryptographic signa- 
ture being calculated using said cryptographic signa- 
ture key; 

calculating said cryptographic signature of said smart card 
application once said smart card application has been 
loaded onto said smart card, said calculating being 
performed by said card domain application using said 
cryptographic signature key provided to said card 
application, whereby said element of checking may be 
performed by said card domain application. 

3. A method as recited in claim 1 further comprising: 
decrypting said smart card application by said card 

domain application once said smart card application 
has been loaded, whereby said smart card application is 
loaded onto said smart card post-issuance in a secure 
manner. 

4. A method as recited in claim 3 further comprising: 
providing a cryptographic encryption key to said card 

domain application before said smart card application 
is loaded onto said smart card; 

encrypting said smart card application using said crypto- 
graphic encryption key before said smart card applica- 
tion is loaded onto said smart card; and 

wherein said element of decrypting being performed by 
said card domain application uses said cryptographic 
encryption key provided to said card domain 
application, whereby said smart card application is 
loaded onto said smart card post-issuance in a secure 
manner. 

5. A method as recited in claim 1 further comprising: 
loading personalization data for said smart card applica- 
tion onto said smart card under control of said card 
domain application; and 


checking a cryptographic signature of said persona liza- 
tion data using said card domain application, whereby 
said personalization data for said smart card application 
is loaded onto said smart card post- issuance in a secure 
5 manner. 

6. A method as recited in claim 1 wherein said smart card 
further includes a security domain application arranged to 
manage the security of post-issuance loading of 
applications, and said element of checking is performed by 

]0 said security domain application. 

7. A method as recited in claim 1 wherein details of said 
clement of checking said cryptographic signature are kept 
confidential from an issuer of said smart card. 

8. A method for loading a smart card application onto a 
]5 smart card after said smart card has been issued to a 

cardholder, said method comprising: 

issuing said smart card to a cardholder, said smart card 
including a card domain application arranged to man- 
age the post-issuance loading of applications and a 
20 security domain application arranged to manage the 
security of post-issuance loading of applications; 
establishing communication between said smart card and 

a provider of said smart card application; 
loading said smart card application onto said smart card; 
25 and 

invoking a cryptographic service of said security domain 
application to validate said smart card application, 
whereby said smart card application is loaded onto said 
smart card post-issuance in a secure manner. 
30 9. A method as recited in claim 8 further comprising: 
providing a cryptographic signature key to said security 
domain application before said smart card application 
is loaded onto said smart card; 
signing said smart card application using a cryptographic 
signature before said smart card application is loaded 
onto said smart card, said cryptographic signature 
being calculated using said cryptographic signature 
key; 

calculating said cryptographic signature of said smart card 
application once said smart card application has been 
loaded onto said smart card, said calculating being 
performed by said security domain application using 
said cryptographic signature key provided to said secu- 
rity domain application, whereby said smart card appli- 
cation is validated. 

10. A method as recited in claim 8 further comprising: 
decrypting said smart card application by said security 

domain application once said smart card application 
has been loaded, whereby said smart card application is 
validated. 

11. A method as recited in claim 10 further comprising: 
providing a cryptographic encryption key to said security 

domain application before said smart card application 
is loaded onto said smart card; 
encrypting said smart card application using said crypto- 
graphic encrypt ion key before said smart card appli- 
cation is loaded onto said smart card; and 
wherein said element of decrypting being performed by 
60 said security domain application uses said crypto- 
graphic encryption key provided to said card domain 
application. 

12. A method as recited in claim 8 further comprising: 
loading personalization data for said smart card applica- 

65 lion onto said smart card; and 

invoking a cryptographic service of said security domain 
application to validate said personalization data, 
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whereby said personalization data for said smart card 
application is loaded onto said smart card post- issuance 
in a secure manner. 

13. A method as recited in claim 8 wherein details of said 
element of invoking a cryptographic service are kept con- 
fidential from an issuer of said smart card. 

14. A method as recited in claim 8 wherein said crypto- 
graphic service provides encryption, decryption, MACing, 
hashing or a digital signature technique. 

15. A smart card arranged to load an application onto said 
smart card after said smart card has been issued to a 
cardholder, said smart card comprising: 

a card domain application arranged to manage loading of 

said application onto said smart card; and 
a security domain application arranged to manage the 
security of post-issuance loading of applications, said 
security domain application including 
a cryptographic key associated with said application, 
a cryptographic service for validating said application 
after said application has been loaded post-issuance, 
said cryptographic service using said cryptographic 
key, and 

a key management function associated with said cryp- 
tographic key, whereby said application may be 
loaded onto said smart card post-issuance in a secure 
manner using said security domain application. 

16. A smart card as recited in claim 15 wherein said 
cryptographic key is an encryption key and wherein said 
cryptographic service is decryption, whereby said security 
domain application may decrypt said application after load- 
ing of said application onto said smart card. 

17. A smart card as recited in claim 15 wherein said 
cryptographic key is a signature key and wherein said 
cryptographic service calculates a digital signature, whereby 
said security domain application may check a signature of 
said application after loading of said application onto said 
smart card. 

18. A smart card as recited in claim 15 wherein said key 
management function is loading or updating of a key. 

19. A smart card as recited in claim 15 wherein security 
aspects of said security domain application are kept confi- 
dential from said card domain application. 
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20. A smart card arranged to load a plurality of applica- 
tions onto said smart card after said smart card has been 
issued to a cardholder, said smart card comprising: 

a card domain application arranged to manage loading of 
said applications onto said smart card; 

a first security domain application arranged to provide 
security for a first application to be loaded post- 
issuance, said first security domain application includ- 
ing 

a first cryptographic key associated with said first 
application, said first cryptographic key being kept 
secret from said card domain and from a second 
security domain application; and 
said second security domain application arranged to pro- 
vide security for a second application to be loaded 
post- issuance, said second security domain application 
including 

a second cryptographic key associated with said second 
application, said second cryptographic key being 
kept secret from said card domain and from said first 
security domain application, whereby said first and 
second applications may be loaded securely post- 
issuance using said first and second cryptographic 
keys, respectively. 

21. A smart card as recited in claim 20 wherein said first 
cryptographic key is an encryption key or a signature key 
and wherein wherein said second cryptographic key is an 
encryption key or a signature key. 

22. A smart card as recited in claim 20 further comprising: 
a cryptographic service included with said first security 

domain for validating said first application after said 
first application has been loaded post-issuance, said 
cryptographic service using said first cryptographic 
key, the details of said cryptographic service being kept 
secret from said card domain application and from said 
second security domain application. 

23. A smart card as recited in claim 20 further comprising: 
a key management function included with said first secu- 
rity domain application. 

24. A smart card as recited in claim 23 wherein said key 
management function is loading or updating of a key. 
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METROLOGY DEVICE WITH It would be advantageous to add secure programmability 

PROGRAMMABLE SMART CARD to a meter in order to expand the meter's functionality 

without interfering with the meter's metrological functions. 

The invention relates to metrology devices and, in 

particular, to a metrology device with a programmable smart 5 SUMMARY OF THE INVENTION 

caf d. The invention relates to adding a programmable smart 

card to a metrology device to expand the device's function- 
ality while still maintaining independent operation of the 

Metrology devices, or meters, can be used to measure device, 

electricity, water, gas, and other commodities, and can be In general, in one aspect, the invention relates to a 

found in metering applications such as parking meters, metrology device comprising a metrology unit, a control 

payphones, weighing machines, etc. A typical metrology circuit connected to the metrology unit, and a smart card 

device simply measures a duration, frequency, or amount of interface connected to the control circuit. The control circuit 

a particular commodity and reports what was measured. ^ is configured so as to be able to communicate with a 

Referring to FIG. 1, a prior art meter 10 typically has a programmable smart card through the interface. In one 

central control circuit 12 which is connected to a metrology embodiment, the cont rol circuit is configured to communi- 

unit 14, an I/O unit 16, and a display unit 18. The control cate with a aaya_programmable smart card ?>In another 

circuit 12 has a meter operating system running thereon embodiment, the smart card interface is ISO 7816 compli- 

which controls the operation of the meter 10. The metrology 20 ant. In another embodiment, the smart card interface enables 

unit 14 is connected to one or more sensors 20 which detect full-duplex communication between the smart card and the 

the commodities to be measured, e.g., electricity. The control circuit. In another embodiment, the control circuit is 

metrology unit 14 measures the commodity detected by the able to initiate communication with the smart card. In yet 

sensor 20 and makes this information available to the control another embodiment, the control circuit is configured to 

circuit 12. In some meters, the control circuit 12 actually 25 send commands to the smart card. In yet another 

performs the function of the metrological unit 14 instead of embodiment, t he _controi circuit is^ nfig urartoHsxecu te 

having a separate metrology unit 14 perform the function. commands j^ei yed fro m, the smart^card.jln yet another 

The I/O unit 16 typically includes a keypad or buttons and embodiment, the control circuit is configured to select an 

allows a user to input predefined commands to the meter 10. application to be run on the smart card. 

For example, a user wanting to see how much electricity was 30 In general, in another aspect, the invention relates to a 

consumed last month would simply push the appropriate metrology system comprising a programmable smart card, 

buttons or otherwise enter the appropriate commands, and and a metrology device connected to the smart card and 

the control circuit 12 would retrieve the desired information configured to communicate with the smart card. In one 

and display it on the display unit 18. The display unit 18 may embodiment, the metrology device comprises a metrology 

be, for example, an LED, LCD, or other types of displays. 35 unit, a control circuit connected to the metrology unit, and 

Typically, the accuracy of each meter is tested and certi- a smart card interface connected to the control circuit. In 

fied by an appropriate certification agency before the device another embodiment, the system further comprises a metrol- 

is put into use. The certification is good for the entire life of ogy device housing, wherein the smart card is housed within 

the meter, which is typically around 10 years. Certification the housing. In yet another embodiment, the smart card is 

requires formal "type"0 testing of any change to a meter's 40 selectively removable from the housing. In yet another 

composition or functionality which may affect the meter's embodiment, the system further comprises a meter operating 

metrological function in order to ensure that there arc no system that controls the operation of the meter, wherein the 

adverse effects to the meter's accuracy or performance. meter operating system is isolated from a smart card oper- 

Prior art applications have attempted to add functionality atin £ s y stem - In vel another embodiment, the smart card is 

to the applications by adding smart cards. For example, 45 a Java programmable smart card. 

Schlumberger's "GSM" mobile telephone products now In general, in another aspect, the invention relates to a 

have a Java programmable smart card in the handsets to programmable smart card comprising a storage unit config- 

identify subscribers and provide information about their ured to persistently store a program to be run on the smart 

service providers. However, it is the GSM "network" that card, a memory unit configured to temporarily store a 

performs the metrological functions and not the GSM hand- 50 program to be run on the smart card, and a microcontroller 

set. Apayphone has been developed by Schlumberger Pay- connected to the storage unit and memory unit and config- 

phones that has a Java Virtual Machine incorporated within "red to selectively exec ute a me trology rela ted ft inction. In 

the payphone's operating system which allows the payphone one embodim ent, ^thej|mart^^ 

to interpret and run Java applications. However, jth"e~Java)? gma rt card. ^In anolKeT^rHbociiment, thTlnicrocontrolIer 
iVirtuahMachine is then a^part"of the payphone 'soperatingsss (cxccutcs-thc-metrology-related^ 

s>Stem"as"oppose"d to'being a sepal^te~alid"isolated"functibir^ Irr-anothcr-cmbddimcntrthe-microcontroller-rctricvcs the 
Other applications include utility prepayment meters that metrology related program from a library of available pro- 
have removable smart cards which function as transport grams. 

devices for payment information and allow entry of payment In general, in another aspect, the invention relates to a 
and tariff into the meter. tS"mart~cards,-generaUy,'are^usel3"f6T^60 method of operating a metrology device with a smart card, 
*a^aTietyi)f-applic^^ the method comprising initiating communication with the 
^bank'cardsrand-ide^tifioitib^badges^The smart cards are smart card, selecting an application to be run on the smart 
typicallynencased^in'a^tam'p^r^istant, plastic or metal card, and sending commands to the smart card. In one 
housing about the size of a credit card and contain one or embodiment, the method further comprises receiving corn- 
more embedded integrated circuit devices. The functionality 65 mands from the smart card. In another embodiment, the 
of these smart cards, however, are usually predefined at the method further comprises receiving the smart card into the 
time they are manufactured. metrology device. In yet another embodiment, the method 
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further comprises performing a metrological function inde- insertable into and removable from the metrology device 22. 

pendent of the smart card. In yet another embodiment, the In other embodiments, referring to FIG. 3, the smart card 24 

method further comprises providing a result of a metrologi- may be fixedly installed or otherwise incorporated within the 

cal function to the smart card. In yet another embodiment, housing 38 as shown. A power supply (not shown), such as 

the method further comprises allowing the selected appli- 5 a battery or a mains derived power supply, provides power 

cation to run on the smart card independently of the metrol- 10 the metrology device 22, and also to the smart card 24 

ogy device when connected to the metrology device 22. 

Advantages of the invention include at least the follow- * n ^ ™f where the smart card 24 is insertable into the 

c , c . . « . metrology device 22, the metrology device 22 is provided 

ing: the addition of self-contained and secure programma- . , c • • .u . ^ *>a l 

, , c t . ... , 4 » j » • c in with means for recognizing the smart card 24 such as an 

bility and functionality to a meter; independent operation of 10 . . . . , . , & . & e . ... . 

J . ... * f * * u £ <■ electronic handshake or other means for acknowledging the 

the meter with or without the programmabihty or function- 4 . ~ A r c . ... , L • 

... . • , c ; , & ' rt4l _ smart card 24. In a preferred embodiment, such means is 

ality; and isolation of the meter s operation system. Other .. . ... - 0i ^ . 1 

. J . .... r c . c \y compliant with the ISO 7816 protocol. 

advantages will become apparent from the following t r , 

description and from the claims. ,n opentioMhesiiMitc^^ 

35 .resistantrand'isolated environment within which to performs 

BRIEF DESCRIPTION OF THE DRAWINGS fa variety of functions for the metrolog y device 2 2." By way 

m ^ „ t , . ^of illustration^thersmart^card:24^ouId-storc-cryptographic 

FIG. 1 is a block diagram of a pnor art metrology device. k?ys and= encode/decode data and/or information for^trfc 

FIG. 2 is a block diagram of a metrology device having petrology-device 22Hn-one-example r the-smarrcard 24 

an external programmable smart card. 2Q *could vakdate jmS~authenti^ 

FIG. 3 is a block diagram of a metrology device having f a^hcatioris-for-th^"metrDlogy"22^along-with"^rovia^ 

an internal programmable smart card. c a 5£?ss^crypto^^ 

FIG. 4 is a block diagram of a programmable smart card. services. InanrnfieTexample, the smart card 24 could allow 

FIG. 5 is a block diagram of a metrology device operating the metrology 22 to distinguish between say, electricity 

system and a smart card operating system. 25 consumption during peak versus off-peak hours and a 

, . „ , . different price/rate could be assigned accordingly. One 

FIG. 6 is a block diagram of a metrology device operating advanlage of performing these functions in the smart card 24 

system and an enhanced smart card operating system. mstead of the metrology device 22 is the metrology device 

DETAILED DESCRIPTION OF THE 22 ma y be susce P tiole to probing or tampering, or its 

PREFERRED EMBODIMENTS 30 s^ 111 "^ otherwise compromised, whereas the smart card 24 

is secure and tamper-resistant. _ 

Throughout the description and the figures, elements that Referring to FIGM^the^rograrHm^ble" smart card-24 

are the same will be accorded the same reference numbers. <^ p ^:a Jnicro^^^ to a 

Referring to FIG. 2, a metrology device 22 has a pro- storage_unitl44^nd a^memoi}^^ 
grammable smart card 24 connected thereto. In one 35 42 executes smart card software and programs, carries out 
embodiment, the smart card 24 is a Java programmable meter instructions, and generally manages the flow of data 
smart card such as the Sc h lumb e rger Cy ber flex sma rt card. l0 and from the smart card 24. In some embodiments, the 
rIn~other"emr5odiments7~the smart card 24~may be prcP> microcontroller 42 may include a microprocessor, a pro- 
g rammed or may run applications-pro&ra mmed in other ^> grammable array logic (PAL), an application -specific inte- 
prog^miMg~lan^ metrology device 22 has a 40 gra ted circuit (ASIC), and/or other integrated circuit 
control circuit 26 which is connected to a metrology unit 28, devices. The stora ge unit 4 4, which may include a read-only 
an I/O unit 30, and a display unit 32. The metrology unit 28 memory (ROM) f stores thT pro^ms^and-datartharare']) 
has one or more sensors 34 connected thereto for detecting (j^elTtc^operate'the^ 46, 
a commodity to be measured, e.g., electricity, water, gas, etc. whicrTmayincrae~a7aTdom-access-memory (RAM), tem- 
The control circuit 26 may be a microcontroller, 45 porarily stores the programs and data used by the micro- 
microprocessor, ASIC, PAL, or other integrated circuit controller 42 during program execution. r jew7)T updated 
device. In another embodiment, the control circuit 26 has a fprograms— ap plicati onspor-data~may-be~dowriloaded ^ar~y 
meter operating system running thereon which controls the Cprogramme^nnto-the^smalT^ 

operation of the metrology device 22. fupgrade t he smart card 24 . Also, smart ca rds containing new S 

The metrology device 22 further has a smart card inter- 50 or updated programs, applications, or data^aybTmailed to 

face 36 which connects the metrology device 22 to the smart the desired locations and then inserted into a metrology 

card 24. The interface 36 provides the necessary physical device. The sm art card 24 also has a com munications unit 48 

and electrical connections between the metrology device 22 ^ onnecteg"ther eto__\vhich_allows_th e mic7w»clnl5lleir42~to^ 

and the smart card 24 to allow the metrology device 22 and QransTeTdata to and~fro nrrextemardevigs. 

smart card 24 to communicate with each other. In some 55 In another embodiment, in addition to a physical 

embodiments, the interface 36 is ISO 7816 compliant and interface, the meter also has a software interface which 

the metrology device 22 and smart card 24 communicate isolates the operating system of the meter from the operating 

with each other using the ISO 7816 protocol. Although the system of the smart card. Referring to FIG. 5, a meter has an 

ISO 7816 protocol provides for half-duplex communication, ojcraring-system'SOjmdX^ 

in some embodiments, other protocols may be used to 60 interface-52 to'c^ons primarilpl^l)^nlS e the smart c ard3 

provide, for example, full-duplex communication between 2)r jnitiate^ communic ations with Java a^plicatiorisranrJO) 

the metrology device 22 and the smart card 24. respond to requests for meter services by the Java applica- 

A metrology device housing 38 houses the metrology tion. Similarly, a smart card includes an operating system 54 

device components described above. The housing 38 may be and a smart card software interface 56 that functions pri- 

of any size, shape, or configuration to suit a particular 65 marily to: receive managerial or administrative commands 

metrology application. In one embodiment, the housing 38 and pass those commands onto the smart card operating 

does not house the smart card 24, which is selectively system 54, receive~Java~application~commands"and~pass 
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those commands onto the Java applications, and send meter 
services requests from the Java applications to the meter. 

In operation, for example, the meter operating system 50 
may issue a managerial or administrative command to the 
smart caro\ such as a c ommand Jo Jo.ad a particular appli- 5 
cat ion^ TO^eter^teT facc-SXc^yer^or othe|wis^Hinges^? 

C the comman d 1 0 co mp I y^v i 1 h the ISO 7816„protocol or.other-/ 

'suitable protocolsrand^sehds the command Jo the smar t"cafd> 
(as shown&ythesolid'line arrow). The smart card interface 
56 receives the managerial or administrative command and 30 
passes it to the smart card operating system 54 which may 
then acknowledge the command or otherwise respond to the 
command (as shown by the dashed line arrow). The meter 
interface 52 also allows the meter operating system 50 to 
initiate communication with a selected application, for 
example, a Java application on the smart card and to instruct 15 
the application to perform one or more specific tasks. The 
smart card interface 56 receives the instruction and passes it 
to the appropriate application which may then acknowledge 
or otherwise respond to the instruction. Once an application 
is selected and activated, the application may call on the 20 
meter to provide a certain metrological service. The appli- 
cation may simply issue a request for that service, and the 
smart card interface 56 then converts the request into the 
appropriate protocol and sends the request to the meter. The 
meter interface 52 receives the metrological service request 25 
and passes it to the meter operating system 50. The meter 
operating system 50 determines whether the metrological 
service is available and causes the appropriate service to be 
performed. The results of the service are then sent to the 
application through the meter interface 52. 30 

The software meter interface 52 allows the meter to 
access the smart card's programmability, applications, and 
resources while still allowing the meter to carry out its 
metrological functions independently of the smart card. The 
meter is able to operate normally with or without the smart 35 
card, and the smart card's programmability and functionality 
become available to the meter only when the smart card is 
inserted, installed, or otherwise connected to the meter. This 
arrangement has the advantage in that any functionality 
introduced into the meter by the applicatioas can be easily 40 
proven (type tested) to not affect the accuracy of the met- 
rological functions of the meter, thereby not compromising 
the meter's certification. 

Similarly, the ability of the smart card to download and 
run applications independent of the meter is not affected. 45 
The applications could also be pre-loaded on the smart card 
prior to insertion or installation in the meter. 

In yet another embodiment, referring to FIG. 6, a smart 
card operating system 60, for, for example, a Java program- 
mable smart card, may have various metrological functions 50 
built-in to the operating system 60. For example, if one or 
more metrology related mathematical calculations (e.g., 
average daily use) are repeatedly performed by one or more 
Java applications, the calculations may be incorporated into 
the smart card operating system 60 as native functions of the 55 
operating s ystem 60. ( The functions-may then"be~available"toO 

rall^aya,applications_and ma y be ru n directly^ from th e]) 
operating systcm~60 insteadof inlhcTaya^pplication wftictP^ 

acquires a^JaVa^irnJaPMachine to^interpret thc^a^licaUon^ 
Tfiis~a'rnm^emenrfr of being much faster 60 

because the functions are executed rather than interpreted. 
Also, the functions may require less storage space as a part 
of the operating system 60 compared to a Java application, 
although the size of the operating system 60 may increase. 
In an alternative embodiment, the functions could be imple- 65 
mented as a part of a Java class library 64 which may then 
be made available to all applications. 
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It is to be understood that the embodiments described 
herein are illustrative only, and that other embodiments may 
be derived by one of ordinary skill in the art without 
departing from the scope of the invention. For example, 
referring to FIG. 2, the control circuit 26, metrology unit 28, 
I/O unit 30, display unit 32, sensors 34, and smart card 
interface 36 may all be combined into a single integrated 
circuit device, or an otherwise smaller or larger number of 
integrated circuit devices. 

What is claimed is: 

1. A utility metrology device, comprising: 

a metrology unit for metering usage of a commodity 
selected from the set having the members electricity, 
gas, and water; 

a control circuit connected to the metrology unit; 

a smart card interface connected to the control circuit, 

wherein the control circuit is configured to: 

i) communicate with a programmable smart card 
through the smart card interface; 

ii) send commands to the programmable smart card; 

iii) select an application to be run on the programmable 
smart card; 

iv) instruct said application to perform a specific task; 

v) execute a command from the programmable smart 
card; and 

vi) perform the appropriate service corresponding to 
said command from the programmable smart card; 
and 

a meter operating system that controls the operation of the 
utility metrology device, said meter operating system being 
isolated from a smart card operating system. 

2. The utility metrology device of claim 1, wherein the 
control circuit is configured to communicate with a pro- 
grammable smart card that is programmable in a high level 
language. 

3. The utility metrology device of claim 1, wherein the 
smart card interface enables full-duplex communication 
between the programmable smart card and the control 
circuit. 

4. The utility metrology device of claim 1, wherein the 
control circuit initiates communications with the program- 
mable smart card. 

5. A utility metrology system which may be repro- 
grammcd comprising: 

a metrology device including: 

a metrology unit for metering usage of a commodity 

selected from the set having the members electricity, 

gas and water; 
a control circuit connected to the metrology unit; and 
a smart card interface connected to the control circuit, 
wherein the control circuit is configured to: 

i) communicate with a programmable smart card 
through the smart card interface; 

ii) send a command to the programmable smart card; 

iii) select an application to be run on the program- 
mable smart card; 

iv) instruct said application to perform a specific 
task; 

v) execute a command from the programmable smart 
card; and 

vi) perform the appropriate service corresponding to 
said command from the programmable smart card; 
and 

a meter operating system that controls the operation of 
the device, said meter operating system being iso- 
lated from a smart card operating system; and 
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a programmable smart card connected to the metrology 
device and operable to communicate therewith via said 
smart card interface, said programmable smart card 
including said smart card operating system. 
6. The utility metrology system of claim 5, further com- 
prising a metrology device housing, wherein the program- 
mable smart card is housed within the metrology device 
housing. 
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7. The utility metrology system of claim 6, wherein the 
programmable smart card is selectively removable from the 
metrology device housing. 

8. The utility metrology system of claim 5, wherein the 
programmable smart card is a smart card programmable in 
a high level language. 
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ABSTRACT 


A system and methods are provided for storing and validat- 
ing electronic tickets for multiple venues on a single smart 
card. In accordance with this present embodiment, an oper- 
ating system of the smart card includes a Java Virtual 
Machine and an applet loader key. A shared applet, including 
a venue loader key, is validated with the applet loader key 
and is stored on the smart card. One or more venue applets 
are also stored on the smart card, each with a venue key 
corresponding to an associated venue. Each venue applet is 
validated by the applet loader key and the venue loader key. 
The shared applet is used by the venue applets to interface 
with ticket loaders and ticket validation devices. Tickets are 
purchased for events associated with the venue applets and 
are stored on the smart card in association with the related 
venue applets. Ticket signatures are authenticated with each 
venue applet's venue key. A ticket is cancelled after being 
tendered to gain admittance to an event. 

25 Claims, 5 Drawing Sheets 


r 





SHARED APPLET 
202 

UNITED AIRLINES 
TICKET APPLET 
220 

FLIGHT 007 
SFO TO PIT 
9/25/88 
SEAT 4B 
222 




VENUE KEY ! i APPLET 1 ! VENUE 
„n a i j SIGNATURE s | SIGNATURE 
| j 220b j i 220c 

TICKET 
SIGNATURE 
222a 




SAN FRANCISCO GIANTS 
TICKET APPLET 
210 

PITTSBURGH 
PIRATES 
9/22/98 
SEAT 24A 
212 

PITTSBURGH 
PIRATES 
9/23/98 
SEAT41D 
214 

PITTSBURGH 
PIRATES 
9/24/98 
SEAT 15C 
216 

VENUE ! ■ APPLET 
LOADER KEY ! j SIGNATURE 
202a j ! 202b 

VENUE KEY I ! APPLET ! ! VENUE 
9irL ; ' SIGNATURE i r SIGNATURE 
i I 210b j ! 210c 

TICKET 
SIGNATURE 
212a 

'ticket 

SIGNATURE 
214a 

TICKET 
SIGNATURE 
216a 

APPLET j 
LOADER KEY i 
^ 200a : 

OPERATING SYSTEM (WITH JAVA VIRTUAL MACHINE) 200 


J 


100 


02/19/2004, EAST version: 1.4.1 


U.S. Patent Apr. 10,2001 Sheet 1 of 5 US 6,216,227 Bl 



FIG. 1 


02/19/2004, EAST version: 1.4.1 


U.S. Patent Apr. 10,2001 Sheet 2 of 5 US 6,216,227 Bl 




PITTSBURGH 
PIRATES 
9/24/98 
SEAT 15C 
216 

UJ 

. a: 

UJ P CO 

^ *Z <o 



TICI 
SIGN/ 
21 



PITTSBURGH 
PIRATES 
9/23/98 
SEAT 41 D 
214 

TICKET 
SIGNATURE 
214a 

FLIGHT 007 
SFO TO PIT 
9/25798 
SEAT4B 
222 

TICKET 
SIGNATURE 
222a 

PITTSBURGH 
PIRATES 
9/22/98 
SEAT 24A 
212 

TICKET 
SIGNATURE 
212a 


VENUE 
! SIGNATURE 
220c 

CO 

VENUE 
i SIGNATURE 
210c 

INITED AIRLINES 
riCKET APPLET 
220 


FRANCISCO GIANT 
riCKET APPLET 
210 


APPLET 
: SIGNATURE i 
220b 

APPLET i 
i SIGNATURE : 
| 210b I 



AN I 



VENUE KEY 
220a 

CO 

> 

UJ 

* CO 

UJ 0 





81 


o. 
a 
< 
a 

UJ 

< 

CO 


CM 
O 
CM 


• UJ 
Q.Z (M 


2* CM 
2 UJ S 

! 2 


o 
o 


o 
o 

CM 

lL? 


x 
o 
< 

2 

1 

> 

I 

—3 
I 
H 


2 
LU 
I- 

co 

& 

(3 


2 

LU 

a. 
O 


CM 

CD 


5a 


CM 


02/19/2004, EAST Version: 1.4.1 


U.S. Patent Apr. 10, 2001 Sheet 3 of 5 


US 6,216,227 Bl 



1 

r 

APPLET LOADER QUERIES 
SMART CARD 
302 


f 

SMART CARD INDICATES 
READY TO LOAD APPLET 
304 





NO 


SIGN AND DOWNLOAD 
SHARED TICKETING 
APPLET 
310 


SMART CARD VALIDATES 
SHARED APPLET AND 
RETURNS STATUS 
312 


YES 



NO 


YES 



NO 


SIGN AND DOWNLOAD 
VENUE APPLET 
316 


YES 


SMART CARD VALIDATES 
APPLET AND RETURNS 
STATUS 
318 



END 

320 


FIG. 3 


02/19/2004, EAST version: 1.4.1 


U.S. Patent Apr. 10, 2001 Sheet 4 of 5 US 6,216,227 Bl 


START 
400 


1 

USER SELE 
AND INITIAT 
4( 

CTS TICKET 
ES LOADING 
)2 


r 

TICKET LOADER 
CHALLENGES SMART CARD 
404 



SMART CARD SIGNS 
CHALLENGE (WITH VENUE 
KEY) AND RETURNS IT 
406 


t 

TICKET LOADER 
VALIDATES SIGNATURE 
408 


r 

TICKET CERTIFICATE IS 
GENERATED AND SIGNED 
410 


r 

TICKET DOWNLOADED 
ONTO SMART CARD 
412 



VENUE APPLET VALIDATES 
TICKET SIGNATURE 
414 


FIG. 4 


02/19/2004, EAST version: 1.4.1 


U.S. Patent Apr. 10,2001 


START 
500 


> 


USER PRESENTS SMART 
CARD WITH TICKET 
502 


r 

VALIDATION DEVICE 
CHALLENGES SMART CARD 
504 

1 

r 


SMART CARD SIGNS 
CHALLENGE (WITH VENUE 
KEY) AND RETURNS IT 
506 


Sheet 5 of 5 US 6,216,227 Bl 


/ endN 




SMART CARD CANCELS 
TICKET 
516 



VALIDATION DEVICE 
VERIFIES TICKET DETAILS 
514 

i 



VENUE APPLET TRANSMITS 
TICKET 
512 


VALIDATION DEVICE 
VALIDATES SIGNATURE 
508 


VALIDATION DEVICE 
REQUESTS TICKET DATA 
510 


FIG. 5 


02/19/2004, EAST version: 1.4.1 


US 6,2 

1 

MULTI-VENUE TICKETING USING SMART 
CARDS 

Sun, Sun Microsystems, the Sun logo, Java, and all 
Java-based trademarks and logos are trademarks or regis- 
tered trademarks of Sun Microsystems, Incorporated in the 
United States and other countries. 

BACKGROUND 

This invention relates to the field of electronic commerce. 
More particularly, a system and methods are provided for 
electronic ticketing. 

The use of tickets for sporting venues, entertainment 
events, travel and the like is no longer strictly a mechanical 
function. Ticketing systems have evolved to make use of 
computer systems in various phases of the ticket generation, 
issuance and validation processes. 

For example, in U.S. Pat. No. 5,598,477, issued to Berson, 
a customer submits information concerning a desired ticket 
(e.g., scheduling data pertaining to an airline flight). A data 
processing system sends ticketing information and 
encrypted validation data to a local printing system. The 
local system prints the ticket, which includes the validating 
information encoded in a two-dimensional barcode. The 
customer presents the ticket at flight time, where a validating 
system scans the barcode, transforms the data from physical 
form into digital form and validates it. If valid, the customer 
receives his boarding pass, luggage claim checks, etc. 

Berson, however, still requires the issuance of a paper 
ticket. Paper tickets are, of course, subject to theft, 
mutilation, destruction, loss, etc. In addition, a ticket pro- 
duced according to the Berson system is necessarily good 
for only onetime use. The ticket is physically collected at the 
time of the flight. Two additional disadvantages exist with 
this scheme. First, the use of two-dimensional barcodes 
requires printers capable of producing, and barcode scanners 
capable of reading, such barcodes. Depending upon the 
number of sites at which tickets are printed or accepted, this 
may involve significant cost. Second, the use of crypto- 
graphic means to secure the validation information requires 
a sophisticated key management scheme. 

In a modification of the Berson system, large random 
numbers may be used in place of cryptographic security. A 
particular random number is chosen and printed as a one- 
dimensional barcode on a physical ticket. The use of large 
numbers significantly decreases the chance of a person 
correctly guessing the number assigned to a particular ticket 
for a discrete event (e.g., airplane flight, entertainment 
event). The random numbers are stored in a database acces- 
sible to sites at which the tickets are used. When the ticket 
is presented at a site, the number on the ticket is compared 
to the list of valid numbers stored in the database. This 
scheme still possesses the disadvantages inherent in paper 
tickets, such as destruction or mutilation and the limitation 
to a single use. In addition, without further protection, the 
database of random numbers provides a single point of 
vulnerability. A person with access to the database could 
conceivably generate large quantities of bogus tickets, 

In addition to the above disadvantages, known ticketing 
systems provide admission to only a single event or a single 
site. Also, a paper ticket issued by a known system is not 
generally modifiable without physically replacing the issued 
ticket. In other words, a person who wishes to visit or enjoy 
multiple events or multiple venues must carry and present a 
different ticket for each event or venue. As he or she makes 
plans to visit even more events or venues, additional paper 
tickets must be purchased and carried, thus increasing the 
risk of loss. 
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SUMMARY 

In one embodiment of the invention, a system and meth- 
ods are provided for storing, on a single electronic device 

5 (e.g., smart card, hand-held computer), electronic tickets to 
events offered at multiple venues. In this embodiment, the 
electronic device receives and stores a venue module asso- 
ciated with each venue for which a ticket is purchased. The 
venue module enables the electronic device to store tickets 

1Q for the associated venue, and includes a venue key for 
validating individual tickets. The electronic device also 
receives and stores a shared ticketing module containing 
instructions to be called by one or more venue modules. The 
shared ticketing module includes a "venue loader key" for 

15 validating installed venue modules. 

After the electronic device is configured with the shared 
ticketing module and one or more venue modules, tickets for 
each installed venue module may be stored. In a present 
embodiment of the invention, the electronic device's user 

20 identifies parameters (e.g., event, date, time, seat) for a ticket 
and the corresponding electronic ticket is downloaded from 
a ticket loader, along with a ticket signature. The venue 
module for the corresponding venue module authenticates 
each stored ticket's signature using its venue key. 

25 When a ticket is to be presented for admission to an event, 
in a present embodiment a validation device challenges the 
electronic device by issuing a challenge code. The venue 
module for the event's venue signs the code with its venue 
key and returns the signed code. After the signature is 

30 validated, the electronic device transmits the ticket for the 
event and the ticket is canceled. 

BRIEF DESCRIPTION OF THE FIGURES 

3S FIG. 1 is a block diagram depicting one system in which 

a smart card is used to store venue applets and tickets for 

admission to a venue in accordance with an embodiment of 

the present invention. 

FIG. 2 depicts a smart card populated with multiple venue 
40 applets and tickets in accordance with an embodiment of the 

present invention. 

FIG. 3 is a flow chart demonstrating one method of 

loading a venue applet onto a smart card in accordance with 

an embodiment of the present invention. 
45 FIG 4 is a flow chart demonstrating one method of 

loading a ticket onto a smart card in accordance with an 

embodiment of the present invention. 

FIG 5 is a flow chart demonstrating one method of 

validating a ticket stored on a smart card in accordance with 
50 an embodiment of the present invention. 

DETAILED DESCRIPTION 

The following description is presented to enable any 
55 person skilled in the art to make and use the invention, and 
is provided in the context of a particular application and its 
requirements. The present invention is not intended to be 
limited to the embodiments shown, but is to be accorded the 
widest scope consistent with the principles and features 
60 disclosed herein. 

For example, in a present embodiment of the invention, 
cryptographic means are applied to ensure the security of 
electronic tickets and venue modules, or applets (e.g., small 
Java applications), that are loaded onto smart cards. One 
65 skilled in the art will recognize that the purpose of the 
cryptographic keys described below is to ensure the security 
and authenticity of information stored on a smart card, and 
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does not necessarily rely upon a particular cryptographic 
scheme unless otherwise indicated. Various cryptographic 
keys are therefore described below for various purposes. The 
invention is not limited to a particular method of crypto- 
graphic security, however, and specific embodiments of the 5 
invention may use an asymmetric key scheme, a symmetric 
key scheme, or some other scheme as may be devised. 

In accordance with one embodiment of the invention, a 
system and methods are provided for generating, storing and 
validating electronic tickets for multiple venues. The tickets 10 
are illustratively stored on a standard smart card, although 
other devices are also contemplated such as the PalmPilot by 
3COM Corporation or the iButton by Dallas Semiconductor. 
The stored tickets may be for any occasions for which 
admission or passage may be pre-purchased, such as sport- 15 
ing events, entertainment events, airline flights, automobile 
tolls, etc. Each venue for which a ticket has been stored on 
a smart card in accordance with a present embodiment of the 
invention has an associated applet stored on the smart card. 
A shared ticketing applet is also stored. These applets are 20 
used, as described below, to interface between the smart card 
and ticket/venue loading facilities and between the smart 
card and ticket validation devices. 

FIG. 1 depicts an illustrative system for issuing, storing 
and validating tickets stored on a user's smart card in an 25 
embodiment of the invention. Smart card 100 may comply 
with the ISO 7816 specification for smart cards. As such, it 
is capable of storing various types and amounts of electronic 
data for later retrieval. 

Applet loader 102 loads one or more applets onto smart 30 
card 100. The applets that are loaded onto smart card 100 by 
applet loader 102 enable smart card 100 to store tickets to 
venues associated with the loaded applets. For example, one 
venue applet may correspond to baseball games hosted by 
the San Francisco Giants. Loading this applet enables smart 
card 100 to store tickets for specific games or a range of 
games (e.g., a season pass). Illustratively, applet loader 102 
is configured to load an applet pertaining to a single venue. 
In an alternative embodiment, however, applet loader 102 
loads applets from multiple venues. 

In addition to venue applets (i.e., applets associated with 
individual venues), a shared ticketing applet is also loaded 
onto smart card 100 for use by all venue applets. As 
discussed below, this shared applet provides functions com- 45 
monly available to, and used on behalf of, each of the venue 
applets. 

Ticket loader 104 loads electronic tickets for individual 
events (or a range of events) onto smart card 100. Each smart 
card is capable of storing multiple tickets, for the same or 50 
different events, venues, dates, etc. Illustratively, each ticket 
loaded onto smart card 100 is stored in association with the 
venue applet corresponding to the venue that is hosting the 
event and will accept the ticket. In a present embodiment, a 
venue's applet is loaded onto smart card 100 (e.g., by applet 5S 
loader 102) before a ticket for an event at that venue is 
loaded. 

Illustratively, ticket validation device 106 is located at a 
venue hosting an event for which a ticket is stored on smart 
card 100. Validation device 106 validates the ticket to ensure 60 
that it is for a current event and accepts the ticket based upon 
this validation. 

In a present embodiment of the invention, applet loader 
102, ticket loader 104 and validation device 106 are separate 
electronic systems equipped to accept, read from, and write 65 
to smart card 100. In this embodiment, a user physically 
presents smart card 100 to each system in order to effect the 
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desired transaction. In an alternative embodiment, any or all 
of applet loader 102, ticket loader 104 and validation device 
106 are co-located, particularly the applet loader and ticket 
loader. 

In yet a further alternative embodiment of the invention, 
any or all of applet loader 102, ticket loader 104 and 
validation device 106 comprise a computer system con- 
nected to the Internet or other wide area network. In such an 
embodiment, these systems are accessed by the user through 
a user computer system that is equipped to accept, read from, 
and write to smart card 100. 

FIG. 2 depicts smart card 100 populated with the shared 
ticketing applet, multiple venue applets, and multiple tick- 
ets. Smart card 100 incorporates operating system 200 to 
interface with other devices (such as applet loader 102, 
ticket loader 104 and validation device 106 from FIG. 1) and 
manage the storage and retrieval of information from the 
smart card. Operating system 200 includes, in the illustrated 
embodiment, a Java Virtual Machine (JVM) for operating 
loaded applets. Operating system 200 further includes cryp- 
tographic key 200a (hereinafter termed the "applet loader 
key") for validating applets loaded onto smart card 100. 
Thus, applet signatures 2026, 2106 and 2206 are authenti- 
cated with applet loader key 200a when the applets are 
loaded. Illustratively, applet signatures are created prior to, 
or concurrent with, the loading of the associated applet. 

Shared ticketing applet 202 comprises instructions (e.g., 
in the form of modules, objects, functions, etc.) called upon 
by the various venue applets installed on smart card 100. 
Shared ticketing applet 202 provides functions common to 
each venue applet (e.g., ticket validation, protocols for 
communicating with ticket loader 104 and validation device 
106) and therefore allows each venue applet to be smaller in 
size, thus conserving storage space on smart card 100. For 
example, in one embodiment of the invention shared tick- 
eting applet 202 provides instructions for loading a ticket, 
validating a ticket, and/or canceling a ticket (e.g., after it has 
been used to gain admittance to an event). Shared ticketing 
applet 202 includes cryptographic key 202a (hereinafter 
termed the "venue loader key") to validate individual venue 
applets, as described below. In particular, when a venue 
applet is loaded, shared ticketing applet 202 authenticates 
each applet's venue signature. 

In an alternative embodiment of the invention, shared 
ticketing applet 202 comprises instructions for enforcing or 
ensuring adherence to ticket details. For example, in such an 
embodiment smart card 100 could be iaserted into a smart 
card reader located within a seating area at an event to verify 
that a user is in his or her ticketed seat or to help him or her 
find the correct seat. 

Venue applels 210, 220 are shown installed on smart card 
100. Venue applet 210 illustratively represents home base- 
ball games of the San Francisco Giants. Venue applet 220 
illustratively represents United Airlines flights. Venue 
applets 210, 220 include cryptographic keys 210a, 220a 
(hereinafter termed "venue keys") that are used to authen- 
ticate venue applets 210, 220 to ticket loader 104 prior to 
loading a ticket. Venue keys are also used to validate ticket 
signatures that accompany tickets for the associated venue. 

Venue applets 210, 220 also include applet signatures 
2106, 2206 for validating the venue applets to operating 
system 200. As discussed above, applet signatures are illus- 
tratively created by applet loader 102 prior to, or concurrent 
with, the loading of venue applets. Operating system 200 
then authenticates applet signatures 2106, 2206 with applet 
loader key 200a when the applets are loaded. 
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Venue applets 210, 220 further include venue signatures onto smart card 100 from applet loader 102. Applet loader 

210c, 220c for validating the venue applets to the shared 102 is, in a present embodiment of the invention, a ticket 

ticketing applet. Similar to applet signatures 210fc, 2206, vending machine and is co-located with ticket loader 104. In 

venue signatures 210c, 220 are created prior to or concurrent this embodiment, venue applet 210 is automatically loaded 

with the installation of venue applets 210, 220. When the 5 wne n a Giants' baseball ticket is purchased, unless the applet 

venue applets are loaded, shared ticketing applet 202 ^ already resident on smart card 100. Also, in this ernbodi- 

authenticates the venue signatures. mem shared tick eting applet 202 is automatically loaded if 

Tickets 212, 214, 216 represent particular home ball- nol res ident on smart card 100. In an alternative 

games played at the San Francisco Giants venue. Ticket 222 embodiment, either or both of shared ticketing applet 202 

represents a particular flight offered by United Airlines, from 1Q and venue [et 210 are prc . loaded on smart card i 00 at the 

San Francisco to Pittsburgh, Pa Umc [{ fe manufactured or the time it ^ ^ 

Each Ucket stored on smart card 100 includes information Witfa reference now to FIG . 3> state 300 is a start state. In 

concerning the related event. Fhus, tickets 212, 214 and 216 ^ 3Q2 kt , oader 1Q2 {& M lQ smart card im Qnd 

include information such as the date of the game opponent s tQ download let 210 llustralivcly> lhe owner of 

and an assigned seat number. The information stored in a _ * A /\ • .A. j ■ j • 

ticket is used with the ticket signature, in a present embodi- 35 smarl car ms ?£ th * smart card ! nt0 a ^ oompns- 

ment of the invention, to validate the authenticity of the , m S applet loader 102 and selects applet 210 for installation 

ticket. Thus, the amount and type of information stored with < e f > b J "Seating a desire to purchase Giants baseball 

a ticket varies depending upon the venue, event, type of tickets). In an alternative embodiment, the owner inserts 

ticket, etc. Instead of individual tickets 212, 214 and 216, the smart card 100 int0 a se P arate computer system connected to 

owner of smart card 100 may, for example, have just one 20 a PP let loader 102 via tDe Internet or other communication 

ticket in the form of a season pass. The season pass ticket is link. 

good for more than one date and will therefore include In state 304, smart card 100 indicates that it is prepared to 

information different from tickets 212, 214, 216. load an applet and, in a present embodiment, passes the 

Each of tickets 212, 214, 216 and 222 includes a ticket applet loader information concerning its present configura- 

signature (represented by the numerals 212a, 214«, 21 6a 25 tion (e.g., which applets are loaded, which versions of 

and 222a) generated by ticket loader 104 with a key of the operating system and Java Virtual Machine are installed). In 

corresponding venue. In an embodiment of the invention one embodiment, smart card 100 performs a self-check prior 

using public key encryption (PKE) and asymmetric key to indicating that it is ready to receive an applet, 

pairs, and where venue keys 210a, 220a are public venue Illustratively, the self-check tests the card's ability to store 

keys, the ticket signatures are generated using the private 30 and retrieve data and tests for bad or damaged memory cells, 

keys corresponding to the public keys. In an alternative Information transmitted to applet loader 102 by the smart 

embodiment using symmetric keys (e.g., DES), ticket loader card may include the amount of storage space available on 

104 signs issued tickets with a copy of venue keys 210a, the card. If insufficient space exists for loading the selected 

220a. As mentioned above, when a ticket is loaded onto applet, an error message is displayed for the user, 

smart card 100, the corresponding venue applet validates the 35 In state 306, applet loader 102 determines whether shared 

ticket by authenticating the ticket signature with its venue ticketing applet 202 is already resident on smart card 100. As 

key. described above, shared ticketing applet 202 contains 

One skilled in the art will recognize that an applet stored instructions used by venue applet 210 and other venue 

on smart card 100 is able to keep data private and thus applets. Illustratively, this determination is made based upon 

inaccessible to other stored applets. This prevents one applet 40 information returned to applet loader 102 by smart card 100 

from corrupting or examining tickets associated with a in state 304. 

particular venue applet. In a present embodiment, however, If it is determined in state 306 that shared ticketing applet 

tickets are cancelled or deactivated after being presented to 202 is not installed on smart card 100, the process continues 

validation device 106. In an alternative embodiment, indi- with state 310. Otherwise, in state 308 it is determined 

vidual tickets arc deleted or overwritten. 45 whether venue applet 210 is already loaded on smart card 

Loading an Applet 100. If not, the process proceeds to state 316. If, however, 

In a present embodiment of the invention, the venue both applets are already loaded, the process exits in end state 

applets and the shared ticketing applet that are loaded onto 320. 

smart card 100 comprise executable computer programs or In state 310 the shared ticketing applet is signed (e.g., by 

modules of executable computer code. In a present embodi- 50 applet loader 102), if not already signed, with a crypto- 

ment of the invention, the shared ticketing applet is sub- graphic key complementary to applet loader key 200a (e.g., 

stantially identical from one smart card to another. Further, when using an asymmetric encryption scheme, a "private" 

each venue's venue applets are similar from one smart card key corresponding to "public" key 200a) to create applet 

lo another, except for the venue key and any tickets that may signature 202/? (shown in FIG. 2). The signed applet is then 

be loaded. 55 downloaded lo smart card 100. Illustratively, applets are 

In one embodiment of the invention, venue applets com- downloaded and stored on the smart card in multiple streams 

prise Java applications constructed according to a standard of bytes (e.g., approximately 200 bytes in each stream), and 

method. For example, a file containing the Java program- each stream is validated by an associated checksum. In state 

ming instructions is compiled with a Java compiler to form 312, the smart card validates accurate receipt of the applet 

a binary class file. The class file is then converted into a 60 and, in slate 314, informs the applet loader whether the 

smart card application file. During this conversion process, installation was successful or not. If shared applet 202 could 

the card application file is digitally signed using applet not be correctly loaded, an error message is returned and the 

loader key 200a (shown in FIG. 2) or its complement, process ends at end state 320. 

depending upon the type of cryptographic encryption (e.g., If the installation of shared ticketing applet 202 was 

symmetric or asymmetric). 65 successful or, if it was determined in state 308 that venue 

FIG. 3 depicts an illustrative process by which a signed applet 210 has not been loaded, the process continues at state 

card application file (e.g., applet 210 in FIG. 2) is loaded 316. 
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In state 316, venue applet 210 is signed (if not already In state 408, ticket loader 104 validates the signature 

signed) by applet loader 102 to create applet signature 2106 received from smart card 100. For purposes of this 

and/or venue signature 210c and is then downloaded onto validation, ticket loader 104 possesses a key complementary 

smart card 100 from applet loader 102. Venue key 210a, as to venue key 210a. For example, in an embodiment of the 

discussed below, will be used to authenticate venue applet 5 invention employing asymmetric keys (e.g., RSA), wherein 

210 to ticket loader 104 and to validate tickets loaded from venue key 210a is a public key of the associated venue, 

the ticket loader. Depending upon the type of cryptographic ticket loader 104 possesses the corresponding private key. In 

security that is preferred (e.g., symmetric or asymmetric an embodiment of the invention using symmetric keys (e.g., 

keys), applet signature 2106 and venue signature 210c are Digital Encryption Standard), ticket loader 104 and venue 

created with applet loader key 200a and venue loader 202a, JQ applet 210 possess copies of the same key. If the validation 

respectively, or with their complements. attempt fails, the ticket loading process cither attempts the 

In state 318, smart card 100 validates the downloaded challenge/validation procedure again (up to a limited num- 

applet and indicates to the applet loader that it was success- ber of times) or fails and reports an error, depending upon 

fully loaded or that an error was encountered. Illustratively, the implementation and security concerns, 

smart card 100 validates successful receipt of the applet by Next, in state 410 ticket loader 104 generates and signs 

computing a checksum and comparing it to a checksum 15 ticket 212 for the venue based upon the event data selected 

provided by applet loader 102. In an alternative by the smart card owne^ser. Illustratively, ticket loader 104 

embodiment, applet signature 2106 of the downloaded signs ticket 212 using the same key with which venue applet 

applet is validated using a cryptographic technique corre- 210 was validated in state 408. In state 412, ticket 212, 

sponding to the form of the key used to create the signature. complete with signature 212a, is downloaded and stored on 

In one particular such embodiment, smart card 100 com- 20 smart card 100. 

putes a hash value from the applet and compares it to a hash In state 414, venue applet 210 validates downloaded 
value retrieved from the signature. If they match, the smart ticket 212 by authenticating signature 212a with venue key 
card considers the applet to have been received intact. A 210a and respond with a message indicating success or 
similar process is used to validate a ticket signature when a failure. In an alternative embodiment of the invention, a 
ticket is downloaded. The process then ends at end state 320. 25 second venue key, different from venue key 210a is stored 
Loading a Ticket with venue applet 210 for the purpose of validating down- 
Once a venue applet is loaded onto smart card 100, tickets loaded tickets. The procedure ends with end state 416. 
for events at that venue (e.g., matches or games at a sporting In the presently described embodiment, the process 
field, flights offered by an airline) may be purchased and described above must be followed for each ticket down- 
loaded as well. Venue applets, shared ticketing applet 202 30 loaded from ticket loader 104. In an alternative embodiment, 
and related tickets are, in a present embodiment of the multiple tickets may be selected, processed and downloaded 
invention, loaded in conjunction with each other, as for a single venue at a time, 
necessary, from a combined ticket/applet loader. Validating a Ticket 

FIG. 4 depicts an illustrative procedure for purchasing an In a present embodiment of the invention, tickets are 

electronic ticket to a Giants baseball game (for which venue 35 validated by validation device 106 when presented for 

applet 210 has been installed) from ticket loader 104 and acceptance at the appropriate venue. FIG. 5 depicts an 

installing it on smart card 100. In a present embodiment of illustrative procedure for validating ticket 212 in accordance 

the invention, ticket loader 104 is part of a web server with a present embodiment of the invention, 

connected to a public network such as the Internet. In this S late 500 is a start state. In state 502, a user presents smart 

embodiment, smart card 100 is coupled to a computer 40 card 100 to validation device 106 in order to gain admittance 

system operated by the owner of smart card 100 that is also to the ball game identified in ticket 212. Illustratively, 

connected to the Internet. Tickets are selected using an validation device 106 comprises a computer system config- 

interface for the venue's web server, and then downloaded ured to accept and communicate with smart card 100. 

over the Internet and stored on smart card 100. In state 504, validation device 106 generates and issues a 

With reference now to FIG. 4, state 400 is a start state. In 45 challenge to smart card 100 as was done in the ticket loading 

state 402, the owner of smart card 100 initiates the ticket procedure described above. The random number provided to 

purchasing/loading procedure. In one embodiment of the smart card 100 is signed by venue applet 210, using venue 

invention, the owner first selects an event for which a ticket key 210a, in state 506. In state 508, the validation device 

is desired. In the presently described embodiment, for authenticates the signature using a key complementary to 

example, a baseball game is identified along with the num- 50 venue key 210a. By authenticating the signature returned 

ber and type of seats desired. As another example, the owner with the challenge, validation device 106 is able to validate 

identifies to an airline reservation agent a flight the owner venue applet 210. 

wishes to take, including a dale and time and perhaps a seat. After authenticating the signature, in state 510 validation 

After the smart card owner selects his or her venue/event and device 106 requesLs ticket data retained by smart card 100. 

specifies any necessary or criteria concerning the event, he 55 Venue applet 210 transmits ticket 212 (e.g., the ticket data 

or she signals acceptance of the ticket as configured. and signature) to validation device 106 in state 512. 

In state 404, ticket loader 104 identifies itself to and Illustratively, validation device 106 is only informed of 
challenges smart card 100 in order to authenticate the card stored lickct(s) usable for a current event, which arc iden- 
and/or venue applet 210. Illustratively, the challenge is a tified by the date, time and/or other identifying data. In one 
"zero knowledge proof taking the form of a random num- 60 embodiment of the invention, shared ticketing applet 202 
ber transmitted to smart card 100 by ticket loader 104. In determines the ticket(s) to be identified to validation device 
state 406, venue applet 210 meets the challenge by gener- 106 (e.g., by determining which venue — and therefore 
ating a digital signature with venue key 210a, and returning which venue applet and tickets — corresponds to the valida- 
te result to ticket loader 104. In an alternative embodiment, tion device). Alternatively, venue applet 210 and validation 
venue applet 210 meets the challenge in step 406 by encrypt- 65 device 106 communicate in order to determine which, of 
ing the random number with venue key 210a and returning multiple tickets associated with the present venue, should be 
the result to ticket loader 104. used. 
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In state 514, validation device 106 verifies the ticket data 
(e.g., confirms the date, time, participating teams, seat 
number) and authenticates the ticket signature. If the ticket 
data and signature pass inspection, smart card 100 is 
instructed to cancel or erase ticket 212 and the user is 
admitted. 

In the presently described embodiment of the invention, 
ticket 212 will be overwritten with a future ticket loaded 
onto smart card 100. In an alternative embodiment, tickets 
are not erased or overwritten. 

The foregoing descriptions of embodiments of the inven- 
tion have been presented for purposes of illustration and 
description only. They are not intended to be exhaustive or 
to limit the invention to the forms disclosed. Many modi- 
fications and variations will be apparent to practitioners 
skilled in the art. Accordingly, the above disclosure is not 
intended to limit the invention; the scope of the invention is 
defined by the appended claims. 

What is claimed is: 

1, A method of using an electronic device to store tickets, 
comprising: 

receiving a first venue module associated with a first 
venue, said first venue module including a first venue 
key for validating a ticket for said first venue; 

validating said first venue module with a module loader 
key of the electronic device; 

receiving a shared module said shared module comprising 
an instruction used by said first venue module; 

validating said shared module with said module loader 
key; 

receiving a first ticket for said first venue; 
receiving a first ticket signature associated with said first 
ticket; and 

authenticating said first ticket signature with said first 
venue key. 

2, The method of claim 1, further comprising: 
receiving a second venue module associated with a sec- 
ond venue, said second venue module including a 
second venue key for validating a ticket for said second 
venue; 

validating said second venue module with said module 
loader key; 

receiving a second ticket for an event offered at said 
second venue; 

receiving a second ticket signature with said second 
ticket; and 

authenticating said second ticket signature with said sec- 
ond venue key; 

wherein said first venue is different from said second 
venue. 

3, The method of claim 1, wherein each of said first venue 
module and said shared module include a module signature 
and wherein said validating comprises authenticating the 
module signature of the validated module with the module 
loader key. 

4, The method of claim 1, wherein said shared module 
includes a shared venue key for validating a venue module, 
further comprising validating said first venue module with 
said shared venue key. 

5, The method of claim 1, wherein said receiving a first 
ticket comprises: 

receiving a challenge from a ticket loader; 

signing said challenge with said first venue key; and 

transmitting said signed challenge to said ticket loader. 
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6. The method of claim 1, wherein said receiving a first 
venue module comprises: 

receiving a first series of instructions for processing a 

ticket for an event at a first venue; 
receiving a first venue key for said first venue; 
storing said series of instructions; and 
storing said first venue key in association with said series 
of instructions. 

7. The method of claim 6, further comprising: 
determining whether said shared module is stored on the 

electronic device; and 
replacing said shared module if said shared module is 
stored on the electronic device. 

8. The method of claim 6, wherein said receiving a shared 
module comprises: 

receiving a second series of instructions used by one or 

more venue modules; 
receiving a venue loader key for validating said one or 

more venue modules; 
storing said second series of instructions; and 
storing said venue loader key in association with said 
second series of instructions. 

9. The method of claim 1, wherein said validating said 
first venue module comprises authenticating a module sig- 
nature of said first venue module with a module loader key 
of the electronic device. 

10. The method of claim 1, further comprising canceling 
30 said first ticket. 

11. The method of claim 10, wherein said canceling said 
first ticket comprises marking said first ticket invalid. 

12. The method of claim 7, wherein said replacing said 
shared module comprises: 

35 marking said shared module invalid; and 

receiving a new version of said shared module. 

13. The method of claim 1, further comprising providing 
said first ticket to a validation device of said first venue. 

14. A method of maintaining tickets for multiple venues 
40 on an electronic device, comprising: 

storing a first venue module, wherein said first venue 
module is associated with a first venue and includes a 
first venue key; 
storing a shared module, said shared module comprising 
an instruction used by said first venue module and 
having a shared venue key for validating said Grst 
venue module; 
validating said shared module; 
receiving a challenge from a ticket loader; 
signing said challenge with a first digital signature using 

said first venue key; 
transmitting said signed challenge to said ticket loader; 
receiving a first electronic ticket for said first venue; 
receiving a first ticket signature, said first ticket signature 

being associated with said first electronic ticket; and 
authenticating said first ticket signature with said first 
venue key. 

15. The method of claim 14, further comprising: 
storing a second venue module, wherein said second 

venue module is associated with a second venue and 
includes a second venue key; 
wherein said second venue is different from said first 
venue. 

16. The method of claim 15, further comprising: 
receiving a second electronic ticket for said second venue; 
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receiving a second ticket signature, said second ticket 
signature being associated with said second electronic 
ticket; and 

authenticating said second ticket signature with said sec- 
ond venue key. 5 

17. The method of claim 14, wherein said receiving a 
challenge comprises receiving a randomly generated num- 
ber. 

18. The method of claim 14, wherein said receiving a first 
electronic ticket comprises receiving one or more details of 10 
an event at said first venue. 

19. The method of claim 14, further comprising: 
receiving a second challenge from a validation device at 

said first venue; 

signing said second challenge using said first venue key; 

transmitting said signed second challenge to said valida- 
tion device; and 

transmitting said first electronic ticket. 

20. The method of claim 19, further comprising canceling 20 
said first electronic ticket. 

21. The method of claim 19, wherein said receiving a 
second challenge comprises receiving a randomly generated 
number. 

22. The method of claim 19, wherein said transmitting 25 
said first ticket comprises transmitting one or more details 
comprising said first electronic ticket. 

23. The method of claim 14, wherein said validating 
comprises validating said first venue module with one or 
more of said shared venue key and a module loader key 30 
stored on the electronic device. 

24. An electronic device for storing tickets, said device 
comprising a memory configured to store: 
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a shared module, said shared module comprising an 
instruction used by one or more venue modules and 
having a shared venue key configured for validating 
said one or more venue modules; 

a first venue module associated with a first venue, said 
first venue module including a first venue key for 
validating tickets for said first venue; 

a module loader key for validating one or more of said 
shared module and said first venue module; and 

a first ticket for said first venue, said first ticket having a 
first ticket signature, wherein said first ticket signature 
is authenticatable with said first venue key. 

25. A computer readable storage medium storing instruc- 
tions that, when executed by a computer, cause the computer 
to perform a method of using an electronic device to store a 
ticket, the method comprising: 

receiving a first venue module associated with a first 
venue, said first venue module including a first venue 
key for validating a ticket for said first venue; 

validating said first venue module with a module loader 
key of the electronic device; 

receiving a shared module, said shared module compris- 
ing an instruction used by said first venue module; 

validating said shared module with said module loader 
key; 

receiving a first ticket for said first venue; 
receiving a first ticket signature associated with said first 
ticket; and 

authenticating said first ticket signature with said first 
venue key. 
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SYSTEM AND METHOD FOR 
INSTALLING/DE-INSTALLING AN 
APPLICATION ON A SMART CARD 

CROSS REFERENCE TO RELATED 
APPLICXnON(S) 

This application claims the benefit of U.S. Provisional 
Application No. 60/116,243 filed Jan. 15, 1999. 

FIELD OF THE INVENTION 

The present invention relates to the field of portable 
tokens such as smart cards. More particularly, the present 
invention relates to a smart card capable of dynamically 
installing or de-installing one or more applications. 
Installation/de-installation may be done in the field through 
a terminal, or through an un-secure source such as the 
Internet. 

BACKGROUND OF THE INVENTION 

Most consumers are familiar with credit cards, debit 
cards, and automatic teller machine (ATM) cards. Such 
cards are increasingly used to access, transfer and spend 
money. The back of these cards includes a magnetic strip 
storing encoded information about the cardholder and the 
account(s) accessible by the card. Terminals, including 
ATMs and merchant point-of-sale terminals, read the 
encoded information from the card and access the cardhold- 
er's account to complete a transaction. 

Besides the well-known credit and debit cards, stored 
value cards are becoming increasingly popular. Stored value 
cards are purchased or issued with a specific monetary value. 
When the cardholder desires to use the stored value card to 
purchase goods or services, the card is presented at the point 
of sale and the cost of the goods or services is deducted from 
the value of the card. The cardholder may continue to use the 
stored value card in this manner until all the value has been 
removed from the card. The card may then be discarded, or 
its value may be replenished. Such cards are commonly used 
to pay subway fares or to make long distance phone calls. 

For many types of transactions, however, the current trend 
is away from credit/debit cards and stored value cards, and 
into a class of devices generally called smart cards. Rather 
than employing information encoded on a magnetic strip, 
smart cards include a microprocessor and a memory element 
embedded within a credit card size device. With a 
microprocessor, a smart card is able to interact with a greater 
variety of terminals across a broader range of transactions. 
In this broader range of transactions, the smart card is able 
to communicate more information regarding the cardholder, 
cardholder account, transaction authorization, etc. 

The term "smart card" is used throughout as a convenient 
name for a broad class of devices sometimes referred to as 
portable tokens. Smart cards arc the most common present 
form of portable tokens, but as will be seen hereafter the 
actual physical form of the portable token, as well as the 
specific means by which the portable token communicates 
data to the outside world are not the subject of the present 
invention. 

Smart cards have been used in various applications for 
some time. FIG. 1 shows an exemplary smart card 10. 
Roughly the size of a credit card, smart card 10 includes a 
microprocessor 12 with an integral memory element, and 
conductive contacts 13. Microprocessor 12 is typically a 
single wafer integrated circuit mounted on, or embedded 
within the otherwise plastic smart card. Conductive contacts 
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13 interface with a terminal to electrically transfer data 
between the terminal and the smart card. Other embodi- 
ments of the smart card do not include conductive contacts 
13. Such "contactlcss" smart cards receive information via 

5 proximately coupling, such as magnetic coupling, or via 
remote coupling, such as radio communication. 

The microprocessor 12 and conductive contacts 13 of 
FIG. 1, are shown in some additional detail in FIG. 2. 
Conductive contacts variously include power contacts, at 

10 least one input/output (I/O) port, a reset port, and a clock 
(elk) signal port. Microprocessor 12 comprises a central 
processing unit (CPU) 21 which is generically control logic 
including I/O circuitry 23. Terminal signals variously inter- 
face with CPU 21 through the conductive contacts 13 and 

15 I/O circuitry 23. Microprocessor 12 is associated with a 
memory element 20. The "memory" may be formed on the 
same integrated circuit as the microprocessor, or may be 
formed on a separate device. Generally, the memory 
includes Random Access Memory (RAM) 22, Read Only 

20 Memory (ROM) 24, and read/write memory, such as an 
Electrically Erasable Programable Read Only Memory 
(EEPROM) 26. However, some or all of these presently- 
used memory elements may be replaced by battery backed- 
up RAM, flash memory, or other electronic data storage 

25 media. 

Operating power, a user input keypad, and a display for 
the smart card microprocessor are typically provided by a 
terminal. The term "terminal" broadly indicates any device 
exchanging information with a smart card using any type or 

30 number of data transfer means. A computer, ATM, merchant 
point-of-sale device, telephone, or security control device, 
are present examples of terminals. 
A broad class of terminals nominally include a mecha- 

35 nism detecting the presence of a properly positioned smart 
card. Upon detecting the smart card, the terminal provides 
power to the microprocessor, and typically sends a reset 
(RST) signal to the smart card. The smart card uses the RST 
signal to reset itself, or to initiate an internal reset function. 

40 After reset, the smart card returns an answer-to-reset (ATR) 
signal to the terminal. The nature and protocol for the ATR 
signal is established by International Standards Organization 
(ISO) standard 7816. As established, the ATR is a multi-byte 
signal communicating basic information concerning the 

45 smart card to the terminal. Once such basic information is 
successfully recognized by the terminal, communication, 
i.e., data transfer, between the smart card and the terminal 
can be established. 

Smart cards can be programmed to operate as stored value 

50 cards, credit cards, debit cards, ATM cards, calling cards, 
personal identity cards, critical record storage devices, etc. 
In these varied capacities, a smart card may, at least in 
theory, be designed to use a number of different application 
programs. In actual practice, however, an inability to readily 

55 develop and operate applications from a variety of sources 
has limited the type and number of applications placed on 
the conventional smart card. In fact, most conventional 
smart cards include only a single application, or at most a 
single type of application. 

60 This is not surprising when one considers that from 
programming and implementation perspectives, a conven- 
tional first generation smart cards is little more than an 
embedded application. Looking at FIG. 3 A, such first gen- 
eration cards can be viewed as an application 30 stored in 

65 memory which runs a set of microprocessor-specific instruc- 
tions on hardware resources 32. The term "hardware 
resources" is used to generically indicate the memory and 
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logic circuits, with their associated interfaces, used to in a tangled mess of code. Not surprisingly, while this 

execute microprocessor instructions but may also include inefficient filtering approach to correcting a ROM based 

I/O circuits, power circuits, and the other hardware. Given application works well enough for smart cards running a 

the structure shown in FIG. 3 A, each application must be single application, it would not work for a smart card 

written in a very low level, or machine level language. This 5 running multiple applications from different vendors, 

language is specific to the microprocessor on which the The historic inability to securely modify or upgrade 

application is intended to run. existing smart card applications in the field is just one reason 

The first generation, embedded application programming why smart cards have failed to realize their full commercial 

model offers at least one significant advantage — potential. Many other reasons exist. Prominent among theses 

programming flexibility. Microprocessors are typically able i° reasons is the absence of a true operating system (OS) 

to execute a significant set of instructions. Since an embed- supporting applications from multiple vendors, 

ded application is written at the machine level, the full range A true operating system does not execute commands 

of the microprocessor's instructions set may be accessed and received from the outside world. r \ rms, in the context of a 

utilized by the application. smart cardj a lrue operating system will not (is unable to) 

Unfortunately, such programming flexibility comes at a a5 execute commands received from a terminal. Rather, an 
high price. In order to run an existing application on a operating system serves as a conduit and router for corn- 
different microprocessor, it must often be completely rewrit- mands communicated from a terminal to an application 
ten. Debugging, updating, and testing of embedded appli- stored on the smart card. Additionally, an operating system 
cations are arduous. Further, machine level programming is serves as a conduit through which an application utilizes the 
difficult and requires a great deal of hardware specific 20 hardware resources. In other words, an operating system 
expertise. Embedded programmers are, thus, hard to find provides I/O functions and provides other functionality to 
and expensive to retain. All of these factors combine to applications running on the OS. Since first generation smart 
restrict the number and quality of smart card applications. cards store only the application code, and since this code 
Further, the hardware specific nature of the resulting appli- must necessarily executes commands received from the 
cations contributes to the incompatibility problems which 25 terminal, first generation smart cards do not include an 
characterize conventional smart card applications. operating system. 

Such conventional smart cards do not employ a true l n an attempt to overcome the difficulties, limitations and 

operating system. Rather, a specific application written expense associated with the programing of first generation 

according to the microprocessor instruction set is stored in ^ smart cards, second generation smart cards incorporate an 

ROM and executed in accordance with commands received interpreter. An interpreter can be thought of as a library of 

from a terminal. MPCOS, VisaCash, GSM, and Proton are commands. JAVA and BASIC are common interpreters. A 

examples of such first generation embedded applications. set of commands is defined and identified in the interpreter, 

Because conventional first generation smart cards store any one of which may be "called" by an application. The 

their embedded application in ROM, there is no real oppor- 35 term "call" or "calling" is used throughout to broadly 

tunity to significantly change or modify the application once describe a relationship between two pieces of code in which 

smart cards are fielded. This presents a real problem to smart one piece invokes the other. Commands, functions, defini- 

card issuers, since operating/programming errors and tions and instructions may be used by having one piece of 

oversights, collectively and generically called "bugs," are code call another pieces of code. The foregoing pieces of 

continually identified following release of any smart card 4Q code may reside within the an application or the OS. 

application. Historically, severe bugs may only be remedied Conceptually, an interpreter 33 can be thought of residing 

by physically replacing smart cards in the field with cards between application 30 and hardware resources 32, as 

having an improved version of the application. Card issuers shown in FIG. 3B. Thus, an application running on a second 

and users generally learn to live with less severe bugs. generation smart card gains access to the hardware resources 

Attempts have been made to avoid these unpleasant 45 only through the interpreter which converts a command into 
alternatives by utilizing the EEPROM portion of smart card one or more microprocessor instructions, 
memory, U.S. Pat. No. 5,542,081 allows "filter instructions" The interpreter effectively provides a higher level of 
to be placed in the ROM based application which index an abstraction and a programming language reflecting this level 
address in EEPROM. The EEPROM address thus allows of abstraction with which a broader class of programmers 
subsequent programming steps to be grafted into the existing 50 may effectively write applications. However, the definition 
application stored in ROM. This additional filtering of commands by the interpreter, which promotes program- 
approach does create a mechanism of sorts for mitigating the ming efficiency and standardization, necessarily restricts 
effects of application bugs, but it doe not actually correct the programing flexibility, since an interpreter will never define 
errant application code generating the bug. the entire range of commands theoretically made possible by 

For example, assume an application as written in ROM 55 an unrestricted combination of the microprocessor instruc- 

creates a data object D by performing steps A and then C. In tions. Thus, by use of an interpreter, programming flexibility 

effect, A+C=D. After issuing smart cards with this is traded away for programming ease and standardization, 

application, the issuer identifies an error in the application in The use of an interpreter also slows program execution since 

relation to the creation of data object D. The remedy for this commands must be converted into microprocessor instruc- 

error requires that D be created by steps A, then B, and then eo ti° ns before execution. 

C, i.e., A+B+C-O. The conventional filtering approach Further, since conventional smart cards implement the file 
would first create an "incorrect" D according to the ROM structure defined by ISO-7816, part 4, the use of an inter- 
based application steps, and thereafter delete the incorrect preter comes as an additional penalty to programming 
data object D, and then re-create it using the EEPROM flexibility. That is, ISO-7816, part 4 already confines an 
based application steps identified in the filtering instructions, es application programmer to a certain command set used to 
One can readily see that the filtering approach is very define a standard file architecture. On top of this restriction, 
inefficient, and for more than one or two minor fixes results the interpreter further confines the programmer to another 
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fixed set of commands. If a particular functionality is not powered, and upon de term in ing that the smart card has never 
defined by a command in the interpreter's library, the previously been powered, performing an first-power initial- 
functionality can not be implemented within an application. ization routine. 

For example, if some new smart card application desired The first -power initialization routine comprises inilializ- 

the function of outputting data to a printer, this function 5 ing the read/write memory, locating the application in ROM, 

could not be implemented if the interpreter lacked the and installing the application in read/write memory. The 

necessary command, such as a "PRINT" command com- application may comprise a boot application allowing inser- 

monly associated with desktop computers. Such functional J 100 ° f a n , e *\ data ob J ecl . in !° r ^ a Q d/wr !! e memor y ; a " d } cal 

u r.* « -l . li . .u ■ . . .-11 to a download manager in the OS. Following installation of 

inabilities attributable to the interpreter are particularly applicalion in re f d/write raemory , an in Llization rou- 

exasperating where a sequence of microprocessor mstruc- 30 ^ ^ be formed whicb com ^ buildi a m 

lions might be designed to implement the desired 'new' maDag ement record, and sending an Answer-To-Reset 

function, but where the programmer lacte access to the signal to the teraiinal. The initialization routine might 

microprocessor instruction set because of the obligatory fu TiheT comprise; determining whether a transaction record 

presence of the interpreter. is present in memory, and upon determining that a transac- 

Like the embedded application of first generation smart ]5 tion record is present in memory calling a transaction 

cards, both the application and the interpreter of second manager, and by operation of the transaction manager, 

generation smart cards are stored in ROM. The process of clearing the transaction record. 

correcting bugs is thus complicated by the possibility of Given the potential length of the first-power initialization 

fixing code in one or both of the interpreter and the appli- routine and the initialization routine, before performing 

cation, either the smart card may send a first portion of the ATR 

Even where modification or upgrading to a fielded smart signal to the terminal, and wherein the step of sending the 
card application can be accommodated in the conventional ATR signal to the terminal following the step of building the 
smart card, the physical process of reprogramming must be memory management record comprises sending a second 
performed in a "trusted" device. That is, a terminal con- portion of the ATR signal to the terminal, 
trolled by the smart card issuer must used to reprogram the 25 i n another aspect of the present invention, the ROM- 
smart card application in order to ensure code integrity. This based boot application is installed upon first-power initial- 
is true because conventional smart cards, in and of ization and used to download a new application data object 
themselves, do not have the processing capability or sophis- which is ultimately converted to a new application. To 
tication to verify new programming code. 3o accomplish this, the boot application will return a command 

Rather, conventional smart cards merely store security table when installed, the commands in the table allowing for 

keys which arc exported to the trusted machine during the the download of the new application data object and calling 

security routine used to authenticate the new code. Thus, the of a download manager. When called the download manager 

trusted machine, not the smart card, performs the security will in turn call the new application data object. The new 

routine. Such a process requires that the smart card export 35 application data object will create a command table for the 

proprietary security keys. Once exported, the smart card new application which is stored in read/write memory. 

loses control over the keys, thereby creating a number of Before calling the download manager, the boot application 

additional opportunities for hackers to breach the card's may perform a security verification routine on the new 

security. application data object. 

™ m ,r. _ T . 4n In yet another aspect, the present invention provides a 

SUMMARY OF THE INVENTION <° me , h( * of downloac £ ng a ^ applicatioD f ro £, a termi . 

The present invention provides a system and method by nal into a smart card memory, the memory storing an 

which one or more applications may be securely installed on operating system (OS) and a first application, the method 

a smart card. Additionally, the present invention provides a comprising; calling the first application from the terminal, 

system and method by which one or more applications may 45 by operation of the first application, inserting a new appli- 

be securely de-installed from a smart card. The capabilities cation data object in memory, and converting the new 

of a true operating system running on the smart card are used application data object into the second application. Before 

to facilitate the install and de-install operations. converting the new application data object into the second 

In one aspect, the present invention allows a clear defi- application, the first application may verify the authenticity 

nition to be drawn between manufacture of the smart card 50 of lne new application data object using a digital signature, 

and it's programming. Thus, a method of manufacturing a f° r example. 

smart card is provided, where the smart card comprises a Within this method, the step of converting the new 

microprocessor and a memory, the memory comprising application data object into the second applicalion com- 

ROM and read/write memory. The method comprises stor- prises; calling a download manager in the OS, calling the 

ing at least a portion of an operating system (OS) in ROM, 55 second application from the download manager, and gener- 

storing at least a boot application in ROM, and following ating a command table for the second application, 

complete manufacture of the smart card, providing the smart Command tables and other persistent data records within 

card to an issuer without material data stored in read/write the context of the present invention may be stored and 

memory. 1 Tie material data comprises either a file structure accessed in a file directory using an efficient data record 

or a security key. 60 structure using OS based file manager. 

In another aspect, the present invention provides a method In still another aspect, the present invention provides a 

of initializing a smart card. Assuming the smart card com- method of de-installing an application on a smart card, the 

prises a microprocessor and a memory and the memory smart card comprising a microprocessor and a memory, the 

comprises a ROM and read/write memory, the ROM storing memory storing an operating system (OS) and the 

an operating system (OS) and an application, the method 65 application, the method comprising; deleting all data objects 

comprises; powering the smart card via a terminal, deter- associated with the application, and deleting all data records 

mining whether the smart card has ever previously been associated with the application. 


02/19/2004, EAST Version: 1.4.1 


US 6,390 : 

7 

In a related aspect, step of deleting all data objects 
associated with the application, and deleting all data records 
associated with the application comprises; beginning with a 
1*' data object associated with the application and continuing 
through the N'* data object associated with the application, 5 
for each data object, deleting the data object by operation of 
the application, and calling the file manager, and by opera- 
tion of the file manager, deleting the data record associated 
with the data object. Following deletion of the N'* data 
object and the N'* data record associated with the 10 
application, the method may thereafter delete the application 
data record from memory, and by operation of the memory 
manager reallocate memory space associated with the appli- 
cation as being available. 

is 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows an exemplary smart card; 

FIG. 2 shows the integrated circuit portion of the exem- 
plary smart card of FIG. 1 in some additional detail; 20 

FIG. 3 A illustrates the software/hardware relationship of 
a conventional, first generation smart card; 

FIG. 3B illustrates the software/hardware relationship of 
a conventional, second generation smart card; 

FIG. 4 is a flowchart illustrating a portion of an exemplary 25 
start-up routine including a first initialization routine and an 
initialization routine; 

FIG. 5 is a flowchart illustrating a portion of an exemplary 
start-up routine including an ATR return; 3Q 

FIG. 6 is a flowchart illustrating an exemplary routine by 
which a new application is downloaded; 

FIG. 7 is a flowchart illustrating and exemplary routine to 
accomplish an install event, within the download routine of 
FIG. 6; 35 

FIG. 8 illustrates an exemplary structure for a data record 
used within the present invention; 

FIG. 9 conceptually illustrates a portion of read/write 
memory to further describe an install event; and 

40 

FIG. 10 is a flowchart illustrating an exemplary routine by 
which a new application is de-installed. 

DETAILED DESCRIPTION 

Some limitations inherent in conventional smart cards are 45 
manifest during the manufacturing process. As presently 
required, conventional smart cards pass from the smart card 
manufacturer to the smart card issuer with data necessarily 
stored in nonvolatile, read/write memory, as well as in 
ROM. In the explanation which follows, some arbitrary lines 50 
have been drawn between stages in an exemplary process by 
which smart cards are placed into commercial use. Such 
descriptive lines are intended merely to facilitate the expla- 
nation which follows. To begin, a "manufacturer*' creates the 
physical smart card structure. There arc relatively few smart 55 
card manufacturers in the world, and many present and 
potential smart card issuers. 

As introduced in the foregoing section example, the term 
"smart card" was described with reference to the common 
commercial device shown in FIG. 1. While this example 60 
serves well for the explanations which follow, it should be 
noted that the present invention is broadly applicable to class 
of devices having physical form factors which are different 
from the one illustrated in the example. For example, the 
present invention is readily adapted to Secure Interface 65 
Modules (SIMs) and Secure Access Modules (SAMs). SI Ms 
and SAMs are physically "cut-down" versions of the classic 
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smart card, and are used with telephones and other spaces 
smaller than that typically provided by larger terminals. 
Obviously, the size, shape, nature, and composition of the 
material encapsulating or mounting the microprocessor and 
memory element are not relevant or limiting to the present 
invention. Thus, as used in the description that follows and 
as claimed below, the term "smart card" should be broadly 
read as encompassing any self-contained combination of 
microprocessor and memory element capable of performing 
a transaction with another device, generally referred to as a 
terminal. 

The term "issuer" denotes the party responsible for at 
least one application on the smart card. That is, the issuer is 
the party ultimately responsible for the development, 
implementation, security, and/or utility of an application 
running on the smart card. The manufacturer and the issuer 
may be the same party, but are more likely than not different 
commercial entities. An issuer may sell or distribute smart 
cards directly or through various middlemen until they reach 
the ultimate customer, the "user." 

The fact that a manufacturer will produce smart cards for 
more than one issuer presents some real concerns, given the 
conventional approach to smart card development. Effi- 
ciency requires that the manufacturer generate or mask 
certain code into ROM. Unfortunately, the manufacturer is 
also typically required to place certain data in read/write 
memory. Such data includes, for example, initial file struc- 
ture information and specialized transport keys which are 
necessary to preclude fraudulent use of blank smart cards. 

This requirement that the manufacturer place certain data 
in read/write memory inherently threatens an issuer's ability 
to control access to, and definition of the application. By 
handing a manufacturer proprietary keys, an issuer creates 
an entire range of potential security problems. Since many 
manufacturers are also issuers, or produce smart cards for 
other issuers, the potential for conflicts of interest is very 
real. 

The present invention avoids these problems by providing 
a smart card which may be delivered from the manufacturer 
to an issuer without any data stored in read/write memory. 
The issuer may thus completely define an application with- 
out sharing proprietary information with the manufacturer. 

In one aspect, the present invention accomplishes this 
result by providing a smart card having a true operating 
system (OS), as defined above. For purposes of explanation, 
the OS is said to implement or define a number of functions. 
As used in this capacity, the term "function(s)" should not be 
read as denoting only classic functionally programming 
operations, such as "MOVE," "STORE," "LOOP," etc., but 
should be read as including any operation or data state 
definable within the OS. Typically, an OS function is defined 
by a collection or sequence of instructions. However, an OS 
function might consist of only a single microprocessor 
instruction, or an OS function might be nothing more than 
a particular variable definition. Thus, the term function(s), as 
used throughout, should be construed as something having 
relation to or a definition within the OS. 

In one aspect of the present invention, the OS is used in 
conjunction with an 

Application Programing Interface (API) and/or a Hard- 
ware Application Layer (HAL). These features are described 
in a commonly assigned U.S. patent application Ser. No. 
09/386,290 filed Aug. 31, 1999. The subject matter of this 
application is incorporated herein by reference. 

When present, the API further defines, or indexes, the OS 
functions, or more preferably a subset of the OS functions. 
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In effect, the API forms a library of favorite, or most 
commonly used functions callable by applications on the 
smart card. In the common vernacular of programmers, the 
API is "glue" between the applications and OS. Thus, as a 
command is executed by an application, one or more OS 5 
functions may be called through the API. Conceptually, the 
API may be thought of as a vector table in which OS 
functions are immediately cross-referenced with an address 
in memory to the code implementing the function. Any 
application written for the smart card may make use of the 
API, but unlike the conventional smart card employing an 
interpreter, the application is not required to operate within 
the set of functions indexed within the API. The API, thus, 
provides an efficiency resource defining certain standard 
functions, without constraining an application to the use of 
only the standard functions. 15 

An API allows shared data objects to be defined which 
may be referenced by any application running on the smart 
card. The API index of functions provides a reference for 
programmers during development of an application. As 
such, standardization and consistency of use are obtained. 20 
Further, the API provides an additional level of program- 
ming abstraction above the OS. By consistent recourse to the 
API, applications programmers may literally ignore the 
specific nature of the hardware resources accessed through 
the OS, and may also ignore much of the OS. This level of 2 5 
abstraction allows applications to be written in terms of a 
standard API which are able to run on literally any micro- 
processor. 

The term "command'* is used throughout to denote a data 
or control transaction between a terminal and a smart card 30 
application, or between one application and another. As 
described above, because a smart card according to the 
present invention uses a true OS, the OS can not execute a 
command. Rather, the OS facilitates transmission of the 
command from a terminal (or another application) to the 35 
application. When executed in the application, the command 
may result in one or more calls to the OS for certain 
functions. One or more of these calls may be made through 
the API, or may be made directly to the OS for functions 
which are not indexed within the API. 

40 

However, such function calls from the application to the 
OS, whether through the API or not, are optional — not 
mandatory. Within one aspect of the present invention, a 
smart card application may be stored in native form. That is, 
the application may, in whole or in part, be complied down 45 
to machine executable object code capable of running 
directly on the hardware resources of the smart card without 
any call to the OS. 

The advantages of this option are profound. For example, 
assume in year one that a competent OS defining an 50 
adequate plurality of functions is commercially imple- 
mented on large number of smart cards. Further, assume a 
very popular application "X" runs on smart cards using this 
OS. 

Next, assume in year two that a bright smart card appli- 55 
cations programmer determines to implement an entirely 
new function within application X. The new function may be 
readily implemented using the existing microprocessor 
instruction set, albeit in a previously unheard of sequence, 
but has not been defined within the OS. $0 

In this situation, the conventional first generation smart 
card would require a significant rewrite of the application. 
Further, since the first generation smart cards run on a fixed, 
embedded version of application X, all existing smart cards 
must be replaced with new cards in order to implement an 65 
upgraded version of the application X including the new 
function. 
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Conventional second generation smart cards can not 
implement the new function because the existing interpreter 
does not define it. Thus, in order to upgrade application X in 
second generation smart cards, a new version of the inter- 
preter must be written and downloaded onto each card. Since 
second generation smart cards store the interpreter in ROM, 
and generally lack a mechanism to perform field downloads, 
particularly in relation to an interpreter, such cards must be 
physically replaced in the field in order to provide customers 
with the upgraded version of application X. 

In the context of a smart card system in which code may 
be quickly and easily downloaded in the field, the option of 
having an upgraded application X bypass the OS to directly 
execute the new function in the microprocessor is particu- 
larly profound. For example, the party owning and/or 
administering application X may not be the same party 
owning the OS, and/or the smart card. Thus, the owner of 
application X may lack the ability or authorization to amend 
the OS. Similarly, the new function may be highly propri- 
etary and as such the owner of application X may not wish 
to disclose the function to the OS or smart card provider. 

In any event, application X may be upgraded in the field 
to incorporate code, which when directly executed on the 
microprocessor, provides the new function without call to 
the OS. Such limited amendment of application X leaves all 
other applications and the OS untouched. That is, the OS 
need not be modified to implement the new function. As a 
result, the relationship between the OS and all other appli- 
cations stored on the smart card is not altered. 

Alternatively, the OS might be upgraded to define the new 
function, and thereafter the API might be amended to index 
the new function. The process by which, in another aspect, 
the present invention amends, or replaces ROM -based pro- 
grams such as the OS, API, and HAL or ROM based 
applications is referred to as "patching." Patching is 
described in a commonly assigned U.S. Pat. No. 6,338,435. 
The subject matter of this application is incorporated herein 
by reference. 

In one embodiment of the present invention, the OS and 
one or more applications are stored in ROM. Additional 
applications may be stored in read/write memory, but at least 
the initial bulk of the programs will be stored in ROM. This 
embodiment is presently preferred on a cost basis, but it is 
recognized that as the performance characteristics and rela- 
tive cost of various memory types, i.e., as between ROM, 
EEPROM, and their substitutes like Flash, change over time 
this preference may change. 

Because the present invention provides a smart card 
having a true OS, the smart card memory must store at least 
a "boot" application. That is, because a true OS is unable to 
execute any command received from a terminal, some 
application must be resident on the smart card to receive an 
execute at least one beginning command. Assuming a con- 
ventional relationship in which a manufacturer is asked to 
mask an application(s) into ROM, and define read/write 
memory in relation to the application(s), a smart card 
according to the present invention operates normally, as 
explained below. However, the present invention provides 
much more. 

Assume as one example that an issuer purchases a "mini- 
mar* smart card from a manufacturer. A minimal smart card, 
which when physically produced and delivered to the issuer 
for programming, includes the typical hardware resources, 
i.e., a microprocessor and a memory. The memory will store 
the OS and the boot application in ROM. Read/write 
memory, typically an EEPROM, will be empty. 
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At this point, it is further assumed that the OS defines a and/or read/write memory). Any application stored in 

plurality of functions including a "download manager." The memory might be installed during the first power initializa- 

download manager is a piece of code which is capable of tion routine, but as explained above, an ability within the 

taking a data object stored in memory and converting it into smart card to download additional applications requires that 

a working application on the smart card. The data object thus 5 the application, whatever it other characteristics and wher- 

converted is called an "application data object" to distin- ever it is stored, be able to execute commands inserting a 

guish it from other types of data objects stored in memory. data object and calling the download manager. 

The download manager often cooperates with a file man- With an application installed in read/write memory, the 

ager and a memory manager. These two managers, as smart card ends the first power initialization routine and 

presently preferred, are described in a commonly assigned 1° begins the initialization routine. Alternatively, as shown in 

U.S. patent application Ser. No. 09/386,286 filed Aug. 31, FIG. 4, the initialization routine is begun upon a determi- 

1999, The subject matter of this application is incorporated nation that the smart card has previously been powered 

herein by reference. (40-no). 

The boot application stored in ROM must be capable of The initialization routine may vary from card to card and 
executing at least two commands, or their equivalent: (1) 15 from issuer to issuer, but as presently preferred the initial- 
inserting a data object in read/write memory, and (2) calling ization routine comprises at least; building a memory man- 
the download manager. This statement is particularly true for age mem record (44), clearing a pending transaction, if any, 
the current example of a minimal smart card delivered to the (45), and sending ATR to the terminal indicating that the 
issuer without anything loaded in read/write memory. In smart card is ready to begin a transaction (46). A preferred 
other words, the boot application accomplishes at least one 20 routine by which the memory management record is built is 
task — downloading a second application. This second appli- described in the. commonly assigned application referenced 
cation may have any form, and may even be a new or more and incorporated above, U.S. patent application Ser. No. 
sophisticated boot application. Before performing this task, 09/386,286 filed Aug. 31, 1999. A preferred routine by 
however, the boot application must, like all other applica- which a pending transaction is described in commonly 
tions running on a smart card according to the present 25 assigned U.S. patent application Ser. No. 09/386,287. 
invention, must be "installed." Another aspect of the present invention is described with 

Before explaining the install routine, an exemplary start- reference to the flowchart in FIG. 5. As mentioned above, 

up routine will be described. This start-up routine, which ISO-7816 defines the ATR signal used by conventional 

may include many other features and functions not described 3Q smart cards to initiate communication with a terminal . Given 

here, will be explained with reference to the flowchart the relatively simple nature of conventional smart card 

shown in FIG. 4. operation, the existing ATR protocol does not necessarily 

When power is received in the smart card, it determines contemplate a lengthy start-up routine including some or all 

whether or not power has ever been previously applied to the of the foregoing. It is possible, therefore, for the terminal to 

smart card (40). This determination may be made, for 35 prematurely terminate a session when an ATR signal is not 

example, by examining a predetermined memory location in received within an anticipated period of time, 

read/write memory. If the smart card determines that this is The conventional ATR signal comprises multiple bytes of 

the first time power has been applied (40=yes), it enters a data. The present invention uses this fact, to avoid "timing- 

" first-power initialization routine." As described below, a out" during the Reset signal/ATR exchange routine between 

smart card according to the present invention will preferably 4Q a terminal and a smart card. For example, looking a FIG. 5, 

run an "initialization routine" upon each power up. The upon receiving power and a reset signal, the smart card 

first-power initialization routine is a specialized version of begins a start-up routine (51). Soon after beginning the 

the initialization routine which is run one time following start-up routine, the smart card returns one or more bytes of 

manufacture of the smart card. The first-power initialization the ATR signal (52) to essentially hold the terminal while 

routine may be run at the manufacturer's facility, at the 45 completing the start-up routine (53). Once the start-up 

issuer's facility, or at a terminal in the field when the smart routine is complete, the smart card sends the remaining 

card is first used. Both the first-power initialization routine portion of the ATR signal (54) before entering an I/O loop, 

and the initialization routine are preferably part of the OS, or performing some other function, 

but may be included as part of one or more smart card described above, the smart card must install an appli- 

applications. 5Q ca ij on ^ p ar i 0 f the first-power initialization routine. In fact, 

With reference to FIG. 4, the first-power initialization once the starting environment of the smart card has been 

routine comprises; defining the smart card starting environ- established, additional applications may also be installed at 

ment (41), locating an application in memory (42), and any time. Installed applications may have many forms, and 

installing the application (43). The definition of the smart may perform many tasks. For example, an installed appli- 

card starting environment will very from card to card, but as 5S cation might be completely new to the smart card, or it might 

presently preferred will at least establish a portion of read/ be an upgrade to an existing application. A new application 

write memory for storing global data objects, define a file might be persistent in the smart card until de-installed, or 

directory in read/write memory, and initialize other variable, might be a one-use application which runs once and 

data, and file structures in memory. In effect, defining the de-installs itself immediately thereafter. Where an existing 

smart card starting environment creates a place for subse- 60 application is stored entirely in read/write memory the 

quently installed application to live. upgrade process simply downloads and installs the upgrade 

Once the starting environment has been defined, the boot application, and deletes the existing application, 

application stored in ROM is located (42), and installed (43). Alternatively, the upgrade application might overwrite all or 

This is the case in the present example which assumes that some of the existing application in read/write memory, 

the only application stored in ROM is the boot application. 6 5 As noted above, where an application is written in ROM, 

However, the present invention is also applicable to smart wholly or in part, the process of upgrading, replacing, or 

cards storing multiple applications in memory (i.e., ROM amended such ROM-based applications is referred to as 
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patching. Thus, as used herein, the concept of a "patch" has left inertly residing in read/write memory until needed, if 

meaning with regard to ROM-based code. Applications, the ever. Thus, a rarely used but marketable option to an 

OS, and API are ready examples of typical ROM-based application might be stored in read/write memory as a data 

programs which may be patched. Patches are typically object, without the overhead of a fully installed application 

one-use applications which create read/write memory-based 5 segment, until required, if ever, by a user. Once needed, it 

code. Once established patch code is viewed as just another may be installed and run as part of the application. 

type of application which, in turn, may be upgraded or ™ . . „ . . . . c t . , , . 

■ , ( , „, n ,• ' • „ J 1 ^ The install event described above is further described in 

replaced by a new application. , . , a , , . „.„ _ „ , „ 

A f f ... . 4 . _ ... . - , relation to the flowchart shown in FIG. 7. The install event 

As one of ordinary skill in the art will recognize from the . . „ , , . , . . .. , . f 

foregoing, the term "application" as used herein it not 10 ^ con rolled by he down^ 

limifed to just self-contained programs, but encompasses 10 P a J* of the OS. When called by an application, or within the 
pieces of code which form part of a present, future, or 0S > to a new application the download manager is 
existing application, whether such application is stored in alwavs called in reIatl0n t0 a new data ob J ect ' l - e - a data 
ROM or in read/write memory. ^J** 1 stored in memory but not yet formed into a new 
Thus, regardless of the nature of the downloaded appli- application. At times, depending on the nature of hardware 
cation or its purpose within the smart card, it may be 35 resources and the contents of memory, the download man- 
installed according to the present invention. One presently a S er ma y 1x5 forced t0 relocate the new data object in 
preferred method for installing an a "new" application is read/write memory (71) prior to making the new application, 
described in relation to the flowchart of FIG. 6. To begin, an 0nce P">perly situated in memory, the new data object is 
existing application is called (61). The term "existing appli- callcd b V lhc download manager (72). In the context of the 
cation" is used to denote any responsive piece of code on the 20 download manager, the new data object is really a new 
smart card. An existing application may be stored in ROM application data object as compared with other types of data 
or in read/write memory. It may be a boot application or any ob J ects stored 10 memory. Once called by the download 
other type of application. The existing application then manager, the new application data object will return a 
receives a command to insert a "new data object" (62). Once command table (73). Following return of the command 
the new data object is stored in read/write memory, the 25 table > the download manager will call the file manager (74) 
existing application receives a command to make a "new which wil1 define Wlthin the file directory a data record 
application" (63). The process of making a new application associated with the command table (75). Having previously 
from the new data object may include an authentication established a data record in the file directory for the new 
routine (64), Once the new data object has been application data object, this data record must be updated by 
authenticated, the existing application calls the download 30 cooperation of the download manager and the file manager 
manager (65). The download manager operates on the new 10 reflecl the conversion of the new application data object 
data object to create the new application. This routine is int0 a new application (76). 

referred to as an "install event" (66), and will be described The command table may have various structures or be 

in more detail below. implemented in any number of different algorithms. In 

Of note, the "call" to the existing application, and/or the 35 whatever form, the command table serves to identify every 
commands to download the new data object and make the command executable by the new application. When a corn- 
new application may come from a terminal, another appli- ma nd is received in the OS via an I/O loop, for example, the 
cation running on the smart card, or the OS. smart card OS will seek to identify an application "owning" 

Of further note, the new data object is authenticated by the 40 lhe command, i.e., an application able to execute the corn- 
existing application before the download manager is called mand - 111,5 1S done by reference to the one or more corn- 
to perform the install event. Thus, while the OS may provide mand tables stored ,n memory. Like all persistent data 
the resource necessary to install a new application, the and files m memory, each command table must be 
existing application maintains the security mechanisms by referenced in a file directory. 

which creation of the new application is allowed. This is an 45 In addition to the command table, the new application 

important feature in a system which allows multiple appli- may create any number of additional data objects associated 

cations from multiple vendors to be run on the same smart with the new application. Such additional data objects may 

card using a common operating system. Each issuer thus be data, variables, files, records, sub-applications or any- 

retains complete security control over the downloading of thing else required by the new application. Any additional 

upgrade and replacement applications. The security mecha- 50 data object intended to be persistent in memory will have an 

nism need not be left to the OS and/or shared with the smart associated data record stored in the file directory, 

card manufacturer. FIG. 8 shows an exemplary structure for a data record. In 

Further, this ability to authenticate new programming one aspect of the present invention, each data record in the 

code "on card" allows a smart card according to the present file directory is stored with a known structure or format, 

invention to be updated, or to have a new application added 55 Thus, a command table data record will have the same basic 

in the field through a non-secure transmission medium like structure as all other data records in the file directory. Data 

the Internet. As explained above, conventional smart cards records within a file directory may be distinguished, for 

can only facilitate upgrades, if at all, on trusted machines. example, by their type field. While not required as part of the 

Thus, assuming for the moment that a conventional smart present invention, use of a standard data record structure 

card has the ability to uprade an existing application in the 60 provides notable benefits. As one of ordinary skill will 

field, such upgrading could only be done via a trusted understand, the exact nature, size, and characteristics of this 

machine since the smart card itself could not perform the "standard" data record structure can be left to the individual 

authentication routine required to verify the new code. This programmer. The explanation which follows is merely a 

is true for any new code downloaded to the conventional presently preferred example. 

smart card. 65 FIG. 8 illustrates an exemplary 16-byte data record struc- 

In the exemplary method described above, the new data ture comprising a 2-byte ID field, a 1-byte ownership field, 

object need not be immediately installed. Rather, it may be a 1-byte type field, a 4-byte data field, a 2-byte data length 
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field, and a 6-byte label field. As presently preferred the type 
field and the label field are user definable. That is, an 
application's programmer may use these data record fields 
for any purpose whatsoever. The download manager, file 
manager, memory manager, and the OS in general, do not 
demand that these fields be defined. They are merely vari- 
able data fields associated with a data record. As examples, 
the type field might indicate that the associated data object 
is an application, a command table, a file, or some other type 
data object. The label field might indicate the access type for 
the data record. 

The ID field identifies the data record within the file 
system administered by the OS. The ownership field 
includes ownership information. In the present example, the 
ownership field of the data record contains the unique 
ownership byte previously described. Only the OS may 
access and define the ID and ownership fields in each data 
record. 

The data field and the data length field are related within 
each data record. The data length field specifies the size of 
the data field. In the preferred embodiment, the data field is 
allocated 4 bytes, it's maximum data size. Thus, if the data 
length field indicates that the data is 4 bytes or less in size, 
then the data field stores the actual data associated with the 
data record. If, however, the data length field indicates that 
the data field is greater than 4 bytes in size, the data field 
stores a 4-byte data pointer indicating the beginning address, 
elsewhere in read/write memory at which the actual data 
may be found. 

An example of an install event will now be described with 
reference to FIG. 9. A new application data object 90 has 
already been stored in read/write memory 99. When called 
by the download manager, the new application data object 
returns at least a command table 92 which is stored in 
read/write memory. By operation of the file manager, a 
command table data record 95 is created in the file directory 
98. Other data objects, A and B, may also be created in 
read/write memory as part of the install event. If such 
optional data objects are intended to be persistent with 
read/write memory, each must define a corresponding data 
record in the file directory. After successfully creating the 
new application with all of its associated data objects and 
data records, the download manager and the file manager 
must change the nature of the original data record 91 
associated with the new application data object. 

For example, when stored in read/write memory, the new 
application data object data record indicated ownership by 
the "existing application." In other words, the existing 
application (the boot application in the minimal smart card 
example) which inserted the new application data object into 
read/write memory and called the download manager 
"owned" the new application data object at that time. Once 
converted into a new application the ownership field for the 
new application data record indicates ownership by the OS. 
That is, henceforth, the OS "own" the new application and 
deal with it as with all other previously installed applica- 
tions. Similarly, the type field which once indicated a "data" 
type for the new application data object, is changed to an 
"application" type once the new application has been 
installed. With its data record properly defined in the file 
directory and having a defined command table, the new 
application is ready to receive commands from the OS I/O 
loop, for example. 

By their very size smart cards include a limited set of 
resources. Memory space is perhaps the most critical smart 
card resource. Thus, any attempt to expand the capabilities 
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of conventional smart cards to run multiple applications on 
a true operating system must address the issue of useful 
memory space conservation. The commonly assigned and 
previously incorporated U.S. patent application Ser. No. 

5 09/386,286 discloses a system and method for reallocating 
read/write memory space. To facilitate the return and reuse 
of memory space, one aspect of the present invention 
provides a method of de-installing an application. 
A presently preferred method for de-installing an appli- 

30 cation on a smart card will be explained with reference to the 
flowchart shown in FIG. 10. The illustrated de- install event 
begins when the smart card receives a de-install application 
command in the OS from a terminal (101). The OS locates 
the application "owning" this command (102). Alternatively, 

15 a de-install event may arise from operation of an application 
on the smart card. That is, during operation, a first applica- 
tion may require de-installation of a second application or 
even de-installation of itself. 

However initiated, the application executing the de-install 

20 event calls the download manager (103). The download 
manager calls the application to be de-installed (104). The 
application executing the de-install event may de-install 
itself or de-install some other application. Naturally, the 
ability of a first application to delete a second application 

25 requires the first (executing) application to "own" the second 
(de-installed) application. Such ownership is readily indi- 
cated by the ownership field of associated data record for the 
second application, for example. 

The application to be deleted first deletes all associated 

30 data objects (105). The process of deleting data objects 
typically includes removing the data record associated each 
data object from the file directory. Again, all associated data 
objects may be readily recognized in memory by scanning 
through the file directory searching for data records having 

35 particular ownership field information. Once all associated 
data objects have been deleted, the file manager is called 
(106). The file manager will then delete the file directory 
entry for the data record associated with the de-installed 
application (107). Once the application has thus been 

40 de-installed, the memory manager is called (108), and 
memory space once allocated to the now de-installed appli- 
cation is reallocated as being "available" (109). 

The long term commercial success of smart cards requires 
an ability to upgrade capabilities while the smart card 

45 remains in the user's possession. That is, smart cards must 
be able to receive new applications and upgrade existing 
applications in the field, preferably through non -secure 
media such as the Internet. Any number of conventional 
authentication routines may be used within the context of the 

so present invention to verify data objects and commands. The 
OS of the present invention facilitates any reasonable secu- 
rity routine which may be implemented by a specific appli- 
cation. No one "OS-based" security model need be man- 
dated. 

55 The present invention provides a system and method for 
securely downloading new applications and existing appli- 
cation upgrades. A true smart card operating system is the 
only efficient way to accomplish secure implementation and 
operation of multiple applications from different vendors on 

60 a single card. Further, as smart cards begin to accept multiple 
applications from different vendors, the card's ability to 
install and de-install applications must operate without 
impacting the smart card operating system or other existing 
applications. Since there are relatively few smart card manu- 

65 facturers which provide cards for all issuers, each smart card 
issuer will require a system which allows them complete 
control over the programming of the card. 
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The present invention has been described using several 
examples. The context needed to explain the download 
manager, initialization routine and install/de-install events 
includes some assumptions regarding data record use and 
storage, data record structure, data object organization in 
memory, and the type of memory commonly used. These 
contextual aspects are used to effectively explain the broader 
inventive concepts of the present invention. However, the 
present invention is not limited to the disclosed examples 
and teaching context. Rather the present invention is defined 
by the attached claims. 

What is claimed: 

1. A method of initializing a smart card, the smart card 
comprising a microprocessor and a memory, the memory 
comprising ROM and read/write memory, the ROM storing 
an operating system (OS) and an application, the method 
comprising: 

powering the smart card via a terminal; 

determining whether the smart card has ever previously 

been powered; 
upon determining that the smart card has never previously 

been powered, performing an first -power initialization 

routine. 

2. The method of claim 1, wherein the first-power initial- 
ization routine comprises: 

initializing the read/write memory; 
locating the application in ROM; and 
installing the application in read/write memory. 

3. The method of claim 2, wherein the application com- 
prises a boot application allowing insertion of a new data 
object into read/write memory, and a call to a download 
manager in the OS. 

4. The method of claim 3, further comprising: 
following installation of the application in read/write 

memory, performing an initialization routine, compris- 
ing: 

building a memory management record; and 
sending an Answer-To- Reset (ATR) signal to the ter- 
minal. 

5. The method of claim 4, further comprising: 

before performing the first-power initialization routine, 
sending a first portion of the ATR signal to the terminal; 
and 

wherein the step of sending the ATR signal to the terminal 
following the step of building the memory management 
record comprises sending a second portion of the ATR 
signal to the terminal. 

6. The method of claim 1, wherein upon determining that 
the smart card has previously been powered, performing an 
initialization routine, comprising: 

building a memory management record; and 

sending an Answer-To-Reset (ATR) signal to the terminal. 

7. The method of claim 6, wherein the initialization 
routine further comprises: 

determining whether a transaction record is present in 
memory; and 

upon determining that a transaction record is present in 
memory calling a transaction manager, and by opera- 
tion of the transaction manager, clearing the transaction 
record. 

8. The method of claim 6, wherein the initialization 
routine further comprises, after sending the ATR, entering an 
Input/Output routine. 

9. The method of claim 6, further comprising: 

before performing the initialization routine, sending a first 
portion of the ATR signal to the terminal; and 
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wherein the step of sending the ATR signal to the terminal 
following the step of building the memory management 
record comprises sending a second portion of the ATR 
signal to the terminal. 
5 10. The method of claim 2, wherein installing the appli- 
cation in read/write memory comprises: 
calling the application from the terminal; 
receiving in the application a command to create a com- 
mand table in read/write memory. 
10 11. The method of claim 10, further comprising: 

following creation of the command table in read/write 
memory, creating additional data objects in read/write 
memory. 

15 12. The method of claim 3, wherein installing the appli- 
cation in read/write memory comprises: 
calling the boot application from the terminal; 
receiving in the boot application a first command, and in 
response thereto generating at least one data record and 
20 storing the at least one data record in read/write 
memory. 

13. The method of claim 12, wherein the at least one data 
record is a command table for the boot application. 

14. The method of claim 13, wherein following storage of 
25 the boot application command table, and in responsive to a 

second command from the terminal, downloading a new 
application from the terminal. 

15. The method of claim 14, wherein the step of down- 
loading the new application comprises: 

30 inserting a new application data object in read/write 
memory, and converting the new application data 
object into a new application. 

16. The method of claim 15, wherein the step of convert- 
ing the new application data object into a new application 

35 comprises: 

calling a download manager; 

from the download manager, calling the new application 
data object; 

40 by operation of the of the new application data object, 
creating a command table for the new application; and 
storing the command table in read/write memory. 

17. The method of claim 16, further comprising: 
before calling the download manager, performing in the 

4 5 boot application a security verification routine on the 
new application data object. 

18. A method of downloading a second application from 
a terminal into a smart card memory, the memory storing an 
operating system (OS) and a first application, the method 

50 comprising: 

calling the first application from the terminal; 
by operation of the first application, inserting a new 
application data object in memory; and 
55 converting the new application data object into the second 
application. 

19. The method of claim 18, further comprising: 
before converting the new application data object into the 

second application, verifying the authenticity of the 
60 new application data object within the first application. 

20. The method of claim 19, wherein verifying the authen- 
ticity of the new application data object comprises: 

verifying a digital signature associated with the new 
application data object. 
65 21. The method of claim 18, wherein the step of convert- 
ing the new application data object into the second appli- 
cation comprises: 
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calling a download manager in the OS; 

calling the second application from the download 

manager, and generating a command table for the 

second application. 

22. The method of claim 21, further comprising: 
following generation of the command table, calling a file 

manager in the OS; and 
by operation of the file manager, generating a first data 
record associated with the command table and storing 
the first data record in memory. 

23. The method of claim 22, wherein the step of inserting 
the new application data object comprises: 

calling the file manager in the OS; 

by operation of the file manager generating a second data 
record associated with the new application data object 
and storing the second data record in memory. 

24. The method of claim 23, wherein the first and second 
data records each comprise an ownership field and a type 
field. 

25. The method of claim 24, wherein the step of gener- 
ating the second data record associated with the new appli- 
cation data object comprises: 

defining the ownership field in the second data record to 
indicate first application ownership; and 

defining the type field in the second data record to indicate 
a data object type. 

26. The method of claim 25, wherein the step of gener- 
ating the first data record associated with the new applica- 
tion comprises: 

defining the ownership field in the first data record to 

indicate OS ownership; and 
defining the type field in the first data record to indicate 

an application type. 

27. The method of claim 23, wherein the command table 
comprises an index of all commands executable by the 
second application. 


28. A method of de-installing an application on a smart 
card, the smart card comprising a microprocessor and a 
memory, the memory storing an operating system (OS) and 
the application, the method comprising: 

5 receiving a de-install command; 

locating the application owning the de-install command, 
and by operation of the owning application calling a 
download manager located in the operating system; 
10 by operation of the download manager, deleting all data 
objects associated with the application; and 
deleting all data record associated with the application. 

29. The method of claim 27, wherein the step of deleting 
all data objects associated with the application, and deleting 

15 all data record associated with the application comprises: 
beginning with a I st data object associated with the 
application and continuing through the Nth data object 
associated with the application, for each data object; 
20 deleting the data object by operation of the application; 
and 

calling the file manager, and by operation of the file 
manager, deleting the data record associated with the 
data object. 

25 30. The method of claim 29, wherein an application data 
record associated with the application is stored in memory, 
the method further comprising: 

following deletion of the Nth data object and the Nth data 
3o record associated with the application, deleting the 
application data record from memory. 
31. The method of claim 30, further comprising: 
following deletion of the application data record from 
memory, calling a memory manager and by operation 
35 of the memory manager reallocating memory space 
associated with the application as being available. 
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